| === jalcine is now known as JackyAlcine_ | ||
| === JuN1x_ is now known as JuN1x | ||
| === webjadmin_ is now known as JackyAlcine_ | ||
| micahg | slangasek: your merges seem to be lacking teh Debian changelogs | 01:44 |
|---|---|---|
| slangasek | micahg: sigh | 02:21 |
| slangasek | micahg: sorry | 02:21 |
| RAOF | We should probably get some tooling to detect and reject that. | 02:26 |
| RAOF | It's *way* too easy to neglect. | 02:26 |
| ajmitch | what's that, missing -v? | 02:28 |
| slangasek | missing --package-merge | 02:29 |
| infinity | RAOF: Rejecting just because the .changes is lacking entries seems a bit harsh. We certainly allow much buggier uploads than that. :P | 02:54 |
| RAOF | Only because we can't catch them :)\ | 02:54 |
| infinity | Well, but a truncated .changes isn't a package bug at all. | 02:54 |
| infinity | (Not saying we shouldn't continue to promote a best-practice of -v(last_upload), just that I don't see the point in rejecting if someone forgets) | 02:55 |
| infinity | It doesn't affect the quality of the package at all, nor even the contents of the real changelog, just the mail to -changes, and the upload record in LP. | 02:56 |
| infinity | (And if we're "checking" that it's correct by tearing apart the package and reading the real changelog, then LP could correct both those issues instead of rejecting) | 02:57 |
| RAOF | It'll sometimes cause launchpad bugs that would be closed by a proper changes file to go un-closed. | 02:57 |
| RAOF | Well, making launchpad do the right thing would be nice, too :) | 02:57 |
| infinity | Yes, it can leave bugs unclosed. And the upload can and should fix that. :P | 02:58 |
| infinity | But I still don't see rejecting non-buggy packages as the answer. | 02:58 |
| infinity | I find it about as distasteful as the people who spend hours arguing over someone submitting a patch in the "wrong" format instead of just applying it. | 02:58 |
| infinity | Not that the two things relate at all, but in both cases, it's a question of process, not function. | 02:59 |
| infinity | s/the upload can/the uploader can/ | 02:59 |
| === stokachu is now known as battlemidget | ||
| hallyn | broder: stgraber: to be clear, on that bluez patch, that didn't originate with me | 03:43 |
| hallyn | maybe i didn't do the right thing there, but i wanted to keep the guys' patch going, but didnt' have the rights to do anything but make a new merge proposal myself | 03:43 |
| === webjadmin is now known as JackyAlcine_ | ||
| === emma_ is now known as emma | ||
| === battlemidget is now known as stokachu | ||
| stokachu | can i ask a packaging question here or does that fall under ubuntu-app-devel? | 05:03 |
| RAOF | It depends; is it to do with the development of ubuntu? | 05:05 |
| RAOF | (#ubuntu-motu can also be reasonable for packaging questions) | 05:05 |
| stokachu | ah ok ill try there | 05:05 |
| stokachu | thanks | 05:05 |
| RAOF | Basically - if the objective is to work on a package in the main archive, then either here or #ubuntu-motu is entirely appropriate. | 05:06 |
| pitti | Good morning | 05:42 |
| samy241190 | bdfhjk: Hi | 05:59 |
| apw | the binary packages from the latest linux-meta upload in precise (3.2.0.18.18) seem to be MIA, can't find them anywhere | 06:32 |
| pitti | apw: I binNEWed them an hour ago | 06:35 |
| pitti | they should appear RSN | 06:35 |
| pitti | they should be there now, actually | 06:35 |
| apw | pitti, hmmm, ahh, compat-wireless was added ... didn't spot that | 06:35 |
| * pitti cleans up http://people.canonical.com/~ubuntu-archive/nbs.html | 06:35 | |
| apw | thanks | 06:35 |
| pitti | apw: any chance to get a bumped linux-meta-ti-omap4, too? | 06:38 |
| apw | pitti, will do | 06:38 |
| pitti | cheers | 06:38 |
| pitti | apw: linux-meta added a modules-cw package which depends on a non-existing linux-backports-modules-cw-3.3-3.2.0-18-server | 06:48 |
| pitti | apw: is that binary package going to exist, or does -meta need to drop that? | 06:48 |
| apw | pitti, i believe it will ... /me checks | 06:49 |
| apw | pitti, oh is that in amd64 ? | 06:51 |
| pitti | yes | 06:51 |
| pitti | http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html | 06:51 |
| apw | pitti, ok leave that with me, i think thats a thinko | 06:51 |
| infinity | apw: It won't exist, -server was replaced with generic... | 06:52 |
| infinity | apw: (And you just dropped the cw-server stuff in the last lbm upload) | 06:52 |
| apw | yeah, i'll fix that and get it updated | 06:52 |
| * infinity wonders how deeply he cares about fixing -tools-armadaxp. | 06:54 | |
| pitti | infinity: we could just drop the package temporarily instead, to get rid of the uninstallability? | 07:00 |
| infinity | pitti: If it bugs you terribly, I can just drop it from the meta for now, sure. | 07:00 |
| pitti | it's the one step away from beer :) | 07:02 |
| pitti | well, now two steps since yesterday, but apw is sorting this out | 07:03 |
| infinity | Fine. I'll fix the meta JUST FOR YOU. | 07:04 |
| infinity | Oh man, I'd gotten so used to the syntax hilighting in vim with the incorrect background=, that the new and correct setting just looks weird. | 07:05 |
| infinity | Figures. | 07:05 |
| pitti | infinity: thanks! | 07:06 |
| pitti | infinity: yeah, the new default totally broke here as well; I added "set bg=light" to my .vimrc now | 07:06 |
| pitti | bright text on dark background is just plain wrong | 07:06 |
| infinity | Well, it makes some sense this way. And that bright text definitely would have been unreadable on white backgrounds. | 07:07 |
| infinity | Still. | 07:07 |
| infinity | Weird. | 07:07 |
| infinity | I might flip it back locally too. :P | 07:07 |
| infinity | pitti: I think I stand by my belief that the new default is "correct", and old nerds like us just hate change. | 07:11 |
| pitti | infinity: no, it's a matter of ergonomy | 07:12 |
| pitti | at least for people who work in a bright environment | 07:12 |
| pitti | infinity: which might not apply to night-time workers like you of course :) | 07:12 |
| infinity | pitti: Perhaps, but edit a changelog with bg=dark, and tell me that package name field in incredibly dark blue is actually readable without eye strain. | 07:12 |
| pitti | infinity: oh, it's certainly matching our default terminal colors better | 07:13 |
| infinity | (I'm used to it, and I pretend it's readable, but I'm not sure it actually is) | 07:13 |
| pitti | infinity: but I never said that _those_ were correct either | 07:13 |
| infinity | ;) | 07:13 |
| infinity | pitti: Oh, wait. Do you use white terminals? | 07:13 |
| pitti | yes, of course | 07:14 |
| pitti | well, white-ish | 07:14 |
| infinity | pitti: Oh, kay, then I misunderstood your complaint. | 07:14 |
| infinity | pitti: And I choose to just pretend people like you don't exist. Terminals should be black. ;) | 07:14 |
| infinity | pitti: (But as I noted when the change was being discussed, it shouldn't be hard to make vim smart enough to actually detect the bg hue and DTRT... termcap makes that available) | 07:15 |
| pitti | yeah, and many centuries of experience in book printing just got it all wrong | 07:15 |
| infinity | pitti: So, yeah, someone really should do that. | 07:15 |
| pitti | infinity: indeed I actually thought that vim did that already | 07:15 |
| pitti | until it got that explicit default | 07:15 |
| infinity | pitti: You'd think, but apparently not. :/ | 07:15 |
| infinity | pitti: No, before that default change, I was getting your "light" colours in my black terminals. | 07:15 |
| infinity | pitti: It would be stellar if someone sorted out making it smart. | 07:16 |
| apw | pitti, ok linux-meta is building ... | 07:16 |
| infinity | (And maybe the smart is already there and the Debian package just fails to turn it on or something silly?) | 07:16 |
| === tkamppeter_ is now known as tkamppeter | ||
| infinity | pitti: meta-armadaxp uploaded mit fixen. | 07:20 |
| pitti | infinity: cheers! | 07:20 |
| YokoZar | ScottK: ~email to u-devel -- I see priority: required on apt-cache show libncurses5, which is the same as dpkg... | 07:24 |
| micahg | YokoZar: dpkg is Essential: yes | 07:24 |
| YokoZar | micahg: Ahh I see my source of confusion. I'm not talking about the essential field then, I'm talking about the priority field. Is it not the case that all priority: required packages are installed on a system? | 07:25 |
| YokoZar | (of the system native arch, that is) | 07:25 |
| micahg | YokoZar: no | 07:25 |
| micahg | only Essential: yes | 07:25 |
| YokoZar | so, uh, what's the point? | 07:26 |
| YokoZar | The point of the Priority: Required category, rather | 07:27 |
| micahg | YokoZar: http://www.debian.org/doc/debian-policy/ch-binary.html#s-dependencies | 07:27 |
| micahg | YokoZar: they're generall installed, but you can't depend on them being there unless they're Essential: yes or (usually transitively Essential: yes) | 07:28 |
| YokoZar | micahg: See, I was confused by http://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities which seems to indicate that removing a required package is something that can totally break things (dpkg included), and (perhaps wrongly) interpreted that as being safe to assume they're there | 07:35 |
| micahg | YokoZar: they usually are, also, I'm curious why ${shlibs:Depends} isn't adding the dependency for you | 07:37 |
| YokoZar | micahg: I was wondering that myself. It seems Wine likes to dlopen libraries at runtime and fail gracefully if they're not there by disabling components | 07:38 |
| YokoZar | Which makes me think I have potentially a lot of missing dependencies that are only now coming out. | 07:38 |
| micahg | well, normally that's called friendly :) | 07:39 |
| YokoZar | meh, if the program quits on startup because it can't dlopen a particular library, it might as well be flat out linked against it | 07:39 |
| YokoZar | (as was the case with libncurses) | 07:39 |
| micahg | yes, I'd suggest that's an upstream bug then | 07:39 |
| apw | pitti, how often does the problems page update? hopefully everything is published | 07:41 |
| dholbach | good morning | 07:55 |
| pitti | apw: every half an hour after the publisher | 08:09 |
| apw | pitti, with luck things should be good by :30 then | 08:10 |
| === smb` is now known as smb | ||
| === webjadmin is now known as JackyAlcine_ | ||
| === webjadmin is now known as jalcine | ||
| cousteau`uni | I have a suggestion for a keyboard layout, where should I send it? | 08:48 |
| cousteau`uni | (it's a modification on the Spanish layout; it adds n- and m-dash, 1/4 and 3/4 fractions, and dead caron) | 08:48 |
| cousteau`uni | I made an xkb file for it; I don't have it here but it's on my PC at home | 08:50 |
| cousteau`uni | (now it's when someone will tell me that xkb isn't used anymore or something like that...) | 08:51 |
| RAOF | cousteau`uni: Upstream is a good place for that - bugzilla.freedesktop.org. | 08:51 |
| cousteau`uni | ok | 08:51 |
| cousteau`uni | Ok, I think I have an account on that site; however I forgot the user and password. Any clue? | 08:55 |
| cousteau`uni | (i.e. user is a name or an e-mail address? and were there any restrictions on the password?) | 08:55 |
| RAOF | email address, no restrictions. | 08:55 |
| jalcine | Reset? | 08:55 |
| cousteau`uni | jalcine: would need the user for that | 08:56 |
| cousteau`uni | RAOF: ok | 08:56 |
| cousteau`uni | I'm starting to think I don't have an account there... | 08:57 |
| === doko_ is now known as doko | ||
| tjaalton | is there a master bug for '..foo/changelog.Debian.gz is different from the same file on the system' install errors? | 09:24 |
| micahg | tjaalton: idk, there's Bug #871083 | 09:27 |
| ubottu | Launchpad bug 871083 in libtasn1-3 (Ubuntu Precise) "gzip -9n sometimes generates a different output file on different architectures" [Medium,Triaged] https://launchpad.net/bugs/871083 | 09:27 |
| tjaalton | micahg: thanks, would that mean a rebuild of the affected packages is needed? | 09:29 |
| micahg | tjaalton: I think so | 09:29 |
| tjaalton | alrighty | 09:30 |
| micahg | dholbach: did you get an FFe for mdbtools, looks like it needed one | 09:32 |
| dholbach | micahg, really? why? | 09:32 |
| micahg | * Added support for REPID (UUID) fields. Thanks Will Daniels from Ubuntu. | 09:33 |
| tjaalton | hmm, though looks like this time the fault was in not having a i386 version update available and the amd64 update failed with that error | 09:33 |
| dholbach | micahg, it's a small patch which makes the exported data a bit more useful by adding another piece of data | 09:35 |
| dholbach | micahg, I didn't read that as a new feature | 09:35 |
| micahg | well, IANA release team member, maybe one can chime in :) | 09:36 |
| dholbach | sure you can :) | 09:36 |
| jalcine | dholbach: loved your post about the Ubuntu weekend :) | 09:37 |
| dholbach | micahg, but in general the update looked like a good idea, as it fixed a crash and it was requested by the debian maintainer who seems to have a look over things, so I felt additionally encouraged :) | 09:37 |
| dholbach | jalcine, thanks a lot | 09:37 |
| dholbach | jalcine, I'm going to write a summary of the activity in a bit | 09:38 |
| micahg | dholbach: oh, I agree it was a good idea, just thought it needed an FFe, that's all :) | 09:38 |
| dholbach | jalcine, and I'm already looking forward to the next Friday :) | 09:38 |
| jalcine | Same here! | 09:38 |
| dholbach | micahg, thanks a bunch for keeping an eye on things :) | 09:38 |
| apw | cjwatson, would we expect an external esata connected drive to be handled sensibly ? ie mounted when connected etc? | 09:42 |
| cjwatson | don't see why not | 09:43 |
| apw | cjwatson, it seems to behave like its an internal drive, it detects it ok as it appears etc, but i have to open 'disk utility' and hit mount to get it moutned | 09:44 |
| infinity | I tend to prefer them to behave like internal ones. | 09:45 |
| infinity | But I'm not sure what the "normal usecase" is. | 09:45 |
| broder | i thought you couldn't tell from udev whether or not a sata drive was esata or internal | 09:46 |
| apw | infinity, yeah not clear cut, but i'd say that could apply to any external drive | 09:46 |
| broder | so udisks treats them all as internal | 09:46 |
| Laney | . | 09:46 |
| Laney | oops | 09:46 |
| apw | broder, then our handling of new internal drives is also poor, as i added this 'internal drive' and there is no interface i can find to make it mount by default | 09:47 |
| apw | yeah i can edit /etc/fstab cause i is smart, but ... | 09:47 |
| infinity | Well, and I use eSATA drives as "normal system" drives. I'm not sure I'd want to deal with the strange races involved in, say, my system trying to simultaenously mount it on my desktop and rebuild a raid array from the cold-swap. | 09:47 |
| apw | infinity, indeed, but i have wanted that in that past with USB drives, an option to say "this is a key drive, the world is over without it" seems reasonable either way | 09:48 |
| apw | pitti, ahhh frothy beer | 09:58 |
| ogra_ | woah | 09:59 |
| ogra_ | ogra@horus:~$ mkdir bin | 09:59 |
| ogra_ | ogra@horus:~$ cp /bin/ls bin/foo | 09:59 |
| ogra_ | ogra@horus:~$ foo | 09:59 |
| ogra_ | Segmentation fault | 09:59 |
| ogra_ | evil | 09:59 |
| apw | ogra_, arm ? | 10:00 |
| ogra_ | apw, yes, works fine if i re-loagin to do a "sudo -i -u ogra" | 10:01 |
| ogra_ | *login | 10:01 |
| apw | ogra_, worked for me not on arm | 10:01 |
| ogra_ | did you have ~/bin in your PATH already ? | 10:02 |
| ogra_ | it only happens for me if it isnt in PATH and i newly create the dir without re-login | 10:02 |
| apw | nope bin not in my path | 10:04 |
| * ogra_ will try on armhf to verify it happens there too | 10:05 | |
| ogra_ | still running el here | 10:05 |
| pkh | is this the right place to discuss kernel issues with the latest beta? | 10:31 |
| ogra_ | try #ubuntu-kernel | 10:31 |
| pkh | cheers. | 10:32 |
| === jodh` is now known as jodh | ||
| * micahg wonders if anyone's interested in processing a round of removals | 11:01 | |
| Daviey | stgraber: Have you seen, bug 946754? | 11:06 |
| ubottu | Launchpad bug 946754 in dnsmasq (Ubuntu) "dnsmasq does not respect/watch '/etc/hosts' updates" [Undecided,New] https://launchpad.net/bugs/946754 | 11:06 |
| dupondje | could somebody have a look at https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/776264 | 11:54 |
| ubottu | Launchpad bug 776264 in cryptsetup (Ubuntu) "Please merge cryptsetup 2:1.4.1-2 (main) from debian unstable (main)" [Wishlist,New] | 11:54 |
| geser | dupondje: have you checked if any packages depending libcryptsetup1 build with the new libcryptsetup-dev? as there was a API change | 12:01 |
| debfx | dupondje: you should subscribe ubuntu-release to the bug, it needs a FFe | 12:10 |
| === _salem is now known as salem_ | ||
| === sunwc_ is now known as sunwc | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === dholbach_ is now known as dholbach | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === kenvandine is now known as ken[out] | ||
| stgraber | Daviey: the latest NetworkManager upload actually turned off /etc/hosts parsing entirely giving that job back to the libc/nss | 14:28 |
| dholbach | jelmer, mvo: mhall119 and I ran into a small problem with UDD work-flows - basically it was just about this use-case: branch ubuntu:geany, use edit-patch to change a .desktop file - the resulting diff is HUGE because of applied quilt patches | 14:39 |
| dholbach | do you think we should add a quilt pop -af; bzr commit -m "unapply quilt patches" step somewhere? | 14:39 |
| dholbach | and where might be a good place for this? | 14:39 |
| dholbach | it's certainly confusing contributors and reviewers alike | 14:39 |
| seb128 | dholbach, that commit idea seems a workaround, it mean you couldn't bzr merge without getting that "buggy commit" in the middle | 14:41 |
| dholbach | seb128, yes it is a workaround | 14:42 |
| dholbach | but it makes things a bit less confusing | 14:42 |
| mhall119 | seb128: right now, making a 1-line change to geany.desktop.in results in a 4745 line diff | 14:42 |
| seb128 | mhall119, dholbach: I'm not saying "right now" is not buggy ;-) | 14:45 |
| dholbach | yeah, it'd be nice to get some advice on what might be a good way of solving it or in the meantime workaround it, so we can let new contributors know what to do | 14:46 |
| * seb128 puts debian dir only desktop vcs use | 14:46 | |
| seb128 | ups, "pets" | 14:46 |
| mhall119 | seb128: I'm going to try and get the quicklist and keywords contributors making proper patches, as requested, but I need an easy-to-follow process that "just works" | 14:47 |
| seb128 | mhall119, yeah, anyway I'm not the one working on that, I was just doing a side comment so I'm stepping out | 14:48 |
| mhall119 | dholbach: it looks like edit-patch *should* be quilt pop'ing all the patches before it commits | 14:49 |
| dholbach | mhall119, the question is: should it commit the unapplied patches into history? | 14:49 |
| mhall119 | so the question is, when there are applied patches on the branch, should they be unapplied in a separate revision from the actual change, or as part of the same revision | 14:50 |
| dholbach | :) | 14:50 |
| mhall119 | not so much "if" as "when" | 14:50 |
| cjwatson | absolutely not in a separate revision | 14:50 |
| mhall119 | cjwatson: why? | 14:50 |
| cjwatson | because each revision should be self-contained | 14:50 |
| cjwatson | if there are applied patches on the branch, then you should leave the branch that way | 14:50 |
| cjwatson | if there are unapplied patches on the branch, then you should leave the branch that way | 14:50 |
| mhall119 | cjwatson: ok, but edit-patch unapplies all patches | 14:51 |
| cjwatson | edit-patch shouldn't be changing the branch handling policy | 14:51 |
| mhall119 | so should edit-patch not be used? | 14:51 |
| cjwatson | surely it should be fixed | 14:51 |
| mhall119 | so that's a bug in edit-patch? If so, I'll file a bug report | 14:53 |
| cjwatson | sounds like it; it should try as hard as possible to leave stuff the way it found it ... | 14:54 |
| === yofel_ is now known as yofel | ||
| === cmagina_ is now known as cmagina | ||
| dholbach | ogra_, were you going to upload https://code.launchpad.net/~gruemaster/flash-kernel/no-mtd/+merge/95618? | 14:56 |
| mhall119 | cjwatson: filed bug #947180 | 14:58 |
| ubottu | Launchpad bug 947180 in devscripts (Ubuntu) "edit-patch should not unapply quilt patches" [Undecided,New] https://launchpad.net/bugs/947180 | 14:58 |
| ogra_ | dholbach, see -changes, already done | 14:59 |
| dholbach | aha | 14:59 |
| ogra_ | (it needed some changes, i didnt bother to ask GrueMaster to change it again but made them on the go) | 14:59 |
| dholbach | ogra_, should it be marked as merged then? | 15:00 |
| jokerdino | hey thanks dholbach ! | 15:01 |
| dholbach | ogra_, or maybe rejected as it wasn't merged as is | 15:01 |
| ogra_ | dholbach, oh, indeed, will do, thanks for the pointer | 15:01 |
| jokerdino | (not intended to be completely random, but was just too excited) | 15:02 |
| dholbach | ogra_, it's possible you can't reject it yourself, but somebody else in here should be able to do it | 15:03 |
| ogra_ | i dont want to reject it ... but mark it merged with the comment that i dropped a misaligned chnage from a former iteration | 15:04 |
| ogra_ | and i think i can mark it as i used to own the branch it wants to be merged in (at least in the past) | 15:04 |
| dholbach | or did you file one already? | 15:07 |
| dholbach | oops :) | 15:08 |
| dholbach | can somebody reject https://code.launchpad.net/~gruemaster/flash-kernel/no-mtd/+merge/95618 please? (fixed in a different way) | 15:18 |
| ScottK | I think ogra_ has to do it. | 15:19 |
| === dendro-afk is now known as dendrobates | ||
| lynxman | Question about packaging, if I wanted to say that package B is an upgrade for B but also obsoletes package A just adding in the control file Replaces: A would be enough? | 15:21 |
| ogra_ | dholbach, so why the heck do i have to do all this crap, it now took me 20min of paperwork for a less than 5 min package fix (incl. upload)... i though UDD would nowadays just take care of it | 15:23 |
| ScottK | lynxman: if it replaces some of the files in A, but not the entire package. If it entirely supercedes it, you need both Replaces and Breaks. | 15:23 |
| dholbach | ogra_, I guess if it's fixed in a different way, the machinery can't figure out which fix it originally was and how it was applied | 15:24 |
| lynxman | ScottK: it entirely supercedes, so Replaces and Breaks then? | 15:24 |
| dholbach | ogra_, I don't know all the internals | 15:24 |
| ScottK | Yes. | 15:24 |
| ogra_ | well, why cant i just mark it merged with a comment that a part of the merge was omitted | 15:24 |
| lynxman | ScottK: cool, thank you :) | 15:24 |
| ScottK | You're welcome. | 15:25 |
| dholbach | ogra_, I'm sure there's a bug open about it - I don't know - I mostly just asked in here and somebody with more powers in LP did it for me | 15:25 |
| ogra_ | ah, seems i can, i just tried it with the wrong button | 15:26 |
| dholbach | aha! | 15:27 |
| * ogra_ was expecting it in the review pulldown at the bottom | 15:27 | |
| stgraber | dpm: hey there, any idea when I can expect a go/no-go from the translations team on bug 926493? | 15:40 |
| ubottu | Launchpad bug 926493 in ubiquity (Ubuntu) "[UIFe] The installer still says your picture will be used on the login screen" [Low,Triaged] https://launchpad.net/bugs/926493 | 15:40 |
| * dpm looks | 15:41 | |
| mhall119 | when running 'quilt' commands, should I be in the ./debian/ directory, or in ./? | 15:44 |
| mhall119 | in ./ it thinks everything is applied but can't find a series file, in ./debian/ it thinks none are applied but it sees the series | 15:44 |
| cyphermox | mhall119: do you have a ~/.quiltrc file? | 15:45 |
| cjwatson | you should not be in the debian/ directory | 15:45 |
| cyphermox | mhall119: sounds like QUILT_PATCHES isn't set | 15:45 |
| mhall119 | cyphermox: no | 15:45 |
| dpm | stgraber, +1'd it with a suggestion | 15:45 |
| cjwatson | http://paste.ubuntu.com/870039/ <- my .quiltrc | 15:45 |
| cjwatson | (though 'export QUILT_PATCHES=debian/patches' is sufficient for a one-off) | 15:46 |
| mhall119 | ok, that got it working | 15:48 |
| mhall119 | it that needed for edit-patch to run? | 15:48 |
| stgraber | dpm: any suggestion on who to poke to get a nice proper english sentence that sounds right? :) | 15:49 |
| mhall119 | ah, nvm, I see it's being set in edit-patch | 15:49 |
| dpm | stgraber, try with mattprice | 15:49 |
| GrueMaster | ogra_: dholbach, what was wrong with my patch (other than maybe no changelog entry (which I thought was autogenerated)). | 15:51 |
| dholbach | GrueMaster, I was just wondering why it was still on the list | 15:51 |
| dholbach | I had no specific comment about the patch itself | 15:51 |
| dholbach | can somebody please reject https://code.launchpad.net/~nik90/ubuntu/precise/software-center/add_quicklist/+merge/94178 from the list? | 15:51 |
| dholbach | err, reject the MP :) | 15:51 |
| stgraber | dpm: ok, poked him | 15:52 |
| GrueMaster | I pushed it Friday, and ogra said he would pull it in today. | 15:52 |
| stgraber | dpm: thanks | 15:52 |
| dpm | stgraber, no worries ;) | 15:52 |
| infinity | stgraber: I prefer the proposed string with s/some/certain/ | 15:52 |
| dholbach | GrueMaster, likely a problem in the machinery - it didn't get the memo | 15:53 |
| GrueMaster | ah. | 15:53 |
| === ken[out] is now known as kenvandine | ||
| mhall119 | mvo: dholbach: cjwatson: https://code.launchpad.net/~mhall119/devscripts/fixes-947180/+merge/95929 | 16:13 |
| mhall119 | that should fix the problem I was having | 16:14 |
| mvo | mhall119: in a call right now, but from looking at it for 3s it looks fine | 16:15 |
| ogra_ | GrueMaster, your patch had changes in the mx5/imx51 section that were bogus, i just omitted them and merged the rest (as i said in the merge comment on LP) | 16:17 |
| GrueMaster | Oh. Actually, they weren't bogus as they actually fixed a potential problem I noticed when editing the code, but I can easily re-add them and push them. I had just forgotten about them when I made the initial no-mtd fix. | 16:19 |
| ogra_ | they wre between two case statements | 16:19 |
| ogra_ | that would have choked heavily :) | 16:19 |
| ogra_ | i thought it was just an accidential paste, the code surely didnt belong where it was | 16:21 |
| TREllis | slangasek: hmmm, don't suppose gconf 3.2.3-2 will make precise? it had some multi-arch fixes | 16:21 |
| GrueMaster | Looking at my actual code, it looks like somehow the ;; got pasted in at the beginning of the if statement. Not sure how that happened. | 16:21 |
| ogra_ | right, thats what gave me the impression there was something wrong with the first bit of the patch | 16:22 |
| ogra_ | but since i had promised you i would merge it asap i took the working part of it :) | 16:22 |
| GrueMaster | Ok. Well, it isn't critical, but it does fix a potential issue of no-mtd on Freescale platforms. I'll fix and repush. | 16:23 |
| GrueMaster | Or push as separate I should say. | 16:23 |
| ogra_ | just give me a pastebin with the patch and i'll upload immediately | 16:24 |
| === Ursinha is now known as Ursinha-lunch | ||
| hrw | is there a command which will grab bug info from launchpad? | 16:32 |
| brendand | hrw, there should be | 16:33 |
| brendand | don't know if there is though | 16:33 |
| brendand | someone could surely whip one up in launchpadlib in a few moments | 16:34 |
| mhall119 | seb128: updated https://code.launchpad.net/~mhall119/ubuntu/precise/geany/add_keywords/+merge/94825 after fixing edit-patch, does it look good now? | 16:43 |
| seb128 | mhall119, if you actually file the "## Description: add some description" "## Origin/Author: add some origin or author" "## Bug: bug URL" yes | 16:44 |
| seb128 | mhall119, that and lp: #.... in the changelog so the bug gets closed on upload | 16:45 |
| mhall119 | seb128: ah, didn't know I had to further edit the patches | 16:46 |
| seb128 | mhall119, well it's clearly written ;-) | 16:46 |
| mhall119 | seb128: written where? edit-patch made it and committed it for me without prompting me to change those parts | 16:47 |
| seb128 | mhall119, at the top of the patches | 16:47 |
| seb128 | mhall119, hum, edit-patch shouldn't commit for you... | 16:47 |
| seb128 | it should create the patch so you can bzr diff | 16:47 |
| seb128 | review your change | 16:47 |
| seb128 | edit if needed, then commit | 16:47 |
| mhall119 | seb128: (LP: 942154) or (Closes: 942154) | 16:49 |
| seb128 | mhall119, lp: #nnnn | 16:49 |
| mhall119 | pushing changes | 16:50 |
| ScottK | mhall119: (Closes: #nnnnnn) is for Debian. | 16:52 |
| === Ursinha-lunch is now known as Ursinha | ||
| jodh | brendand: lptools pkg, wget -O /tmp/${bug}.txt https://bugs.launchpad.net/bugs/$bug/%2Btext, http://people.canonical.com/~jhunt/scripts/lp-show-bug.py (caveat - hideous code). | 17:02 |
| brendand | jodh, would be nice to have something in universe that does it | 17:03 |
| SpamapS | Will precise-backports open early this cycle? | 17:21 |
| * ScottK doesn't think the tech board has approved it yet and there are some LP changes needed in any case. | 17:22 | |
| ScottK | broder: ^^^? | 17:22 |
| Laney | pretty sure they did approve it, but at any rate the implementation isn't ready AFAIK | 17:22 |
| Laney | not sure what the blockers are though | 17:22 |
| Laney | at least n+1 initialisation | 17:23 |
| SpamapS | Ah ok | 17:23 |
| SpamapS | Since we're being conservative and not shipping PHP 5.4.0 , I want to get it into precise-backports early. | 17:23 |
| SpamapS | We've never had a PHP version in backports, but in this case, I think its going to be key given the unfortunate timing of their release. | 17:24 |
| micahg | SpamapS: it will require a install/run test of all the reverse dependencies | 17:30 |
| SpamapS | micahg: I think its time we re-evaluate what "test" means. :) | 17:31 |
| Laney | test already is the loosest it can be | 17:32 |
| === deryck is now known as deryck[lunch] | ||
| micahg | SpamapS: and PHP being what it is, I think we'd have to ask for some type of commitment to keep the backport updated for security patches | 17:32 |
| infinity | Yeah, I don't like the idea of shipping a backport that we think many/most people will end up installing. | 17:33 |
| infinity | At that point, it's worth re-examining the possibility of a freeze exception, with perhaps a loose "and make it 5.4.1 ASAFP". | 17:33 |
| SpamapS | infinity: would you argue instead for just shipping 5.4.0? I've closed that door a few times only to have a few people try and kick it down again. | 17:34 |
| infinity | Cause well all knw dot-zero from php.net is lollerskates pretty much every time. | 17:34 |
| infinity | SpamapS: Well, I really don't want to see 5.3.x not being used in favour of an unsupported backport. | 17:34 |
| SpamapS | infinity: the release process is light years different.. I think this one may be at least better. | 17:34 |
| infinity | SpamapS: And that's what's likely to happen in your scenario. | 17:34 |
| infinity | SpamapS: Unfortunately, many webapps will break horribly with the pass-by-reference changes. | 17:35 |
| SpamapS | infinity: 5.3.x is just as likely to be used by stubborn organizations. | 17:35 |
| infinity | SpamapS: Which is a non-issue for 3rd party stuff, but sucks for anything we ship. | 17:35 |
| SpamapS | 5.4 has a pass by reference change? | 17:35 |
| infinity | Uhm. Yeah. | 17:35 |
| SpamapS | I thought that was 5.3's big suckage | 17:35 |
| SpamapS | infinity: oh, that has been spitting E_WARNING since 5.3 was released 3 years ago. I have almost no sympathy for those people who ignored that change. | 17:36 |
| SpamapS | I think even 5.2 had it as an E_DEPRECATED | 17:37 |
| infinity | SpamapS: As long as nothing in the archive breaks, I don't care. 3rd party upstreams will fix their shit. | 17:37 |
| infinity | SpamapS: But yeah, with my release hat on, if our options are "split the userbase between 5.3.x and an unsupported 5.4.x backport" or "just effin' make 5.4.0 work", I'm for the latter. | 17:37 |
| SpamapS | infinity: Yeah, thats why we're not shipping 5.4.. because *ZERO* people stepped up to test anything in the archive. | 17:38 |
| infinity | SpamapS: That needs some commitment from the server team of making sure it kinda works. | 17:38 |
| infinity | SpamapS: And I care less about webapps here than making sure extensions DTRT, etc. Which should be trivial. | 17:38 |
| infinity | SpamapS: But some few "important" webapps we ship should be tested... | 17:38 |
| SpamapS | I believe I found only 2 php dependencies in main, and they both work fine w/ 5.4 | 17:38 |
| micahg | backports doesn't particularly care about the main/universe split :) | 17:39 |
| SpamapS | but the 107 other reverse deps .. no clue if they work | 17:39 |
| infinity | SpamapS: Putting it in the inverse, I'd be inclined to forbid 5.4.x backports if we ship 5.3.x. :P | 17:39 |
| infinity | SpamapS: So, given all those options, shipping 5.4.x seems the least nasty. | 17:39 |
| infinity | But *some* testing needs to be done. | 17:40 |
| infinity | Really. | 17:40 |
| infinity | At this point in the game, we can't guess. | 17:40 |
| SpamapS | infinity: so, if we went the 5.4.0 route.. we are ignoring the fact that MANY users are only just now migrating to 5.3.x .. so *they* will be even less likely to upgrade to precise. | 17:40 |
| SpamapS | Or they'll go on some wonky unsupported 5.3.x package.. or upstream | 17:40 |
| infinity | I don't see that as an issue. New releases have new software. They'll learn to cope. | 17:40 |
| micahg | SpamapS: that means they skipped lucid as well or so it would seem | 17:40 |
| SpamapS | micahg: there are quite a few questions out there on the forums and askubuntu about how to run 5.2.x on lucid | 17:41 |
| infinity | And yes, lucid was 5.3.x | 17:41 |
| SpamapS | I really want to ship 5.4.0 | 17:41 |
| infinity | People running old releases are more rare than people wanting the new shiny. | 17:41 |
| SpamapS | Ondrej from the Debian PHP team suggested I should do it. | 17:41 |
| PaoloRotolo | Hi all! | 17:41 |
| SpamapS | infinity: hrm.. not sure I agree with that from my experience w/ PHP. Its bass-ackwards from most of the other languages. | 17:42 |
| SpamapS | infinity: thats part of the reason the PHP devs adopted their new stricter release process.. because people were almost completely unable to upgrade due to the insanity of the past 5.1.x -> 5.2.x and 5.2.x -> 5.3.x | 17:42 |
| infinity | From my experience maintaining it in the past, there was always a small set of corporate holdouts that hated rewriting that stayed on old versions for "too long", and everyone else upgraded to CVS versions before they were even released. :P | 17:43 |
| infinity | But that was then. | 17:43 |
| infinity | I'm not sure how things work now, to be fair. | 17:44 |
| SpamapS | Every PHP meetup I go to is full of sad developers who are forced to stay on ridiculously old versions because they have no test suite and tens of thousands of lines of code. | 17:44 |
| infinity | Still, I think shipping a new language version in backports is the wrong answer to any of these questions. | 17:44 |
| SpamapS | I think we should kick them in the shins w/ 5.4 actually | 17:44 |
| infinity | lucid is still supported for 3 more years if people need 5.3 | 17:44 |
| infinity | And heck, hardy is supported for another year, if they need 5.2 | 17:44 |
| SpamapS | ok, since this issue has been raised from the dead I think 5 times now.. it warrants a re-evaluation of my priorities. | 17:45 |
| infinity | To be honest, I'd like to go back in time and spend a couple of weeks on evaluating apache2.4 as well, but at least that one's not "necessary" for anyone, just nice-to-have. | 17:47 |
| micahg | SpamapS: well, that's why I'm shocked by the new PHP roadmap in general, things would seem to be moving too fast for most PHP devs | 17:47 |
| Laney | I wouldn't mind shipping 5.4.* in Precise, but breaking half the Universe package would be uncool, so some evaluation is needed. I also don't think I would forbid a backport on principle if there is a maintenance commitment (aside: we should extend tools like the CVE tracker to cover backports). | 17:47 |
| infinity | And, well, every bit of software has an "I wish it was newer" version. | 17:47 |
| infinity | Laney: If there was a maint commitment, sure, but I don't honestly see that happening. | 17:47 |
| micahg | Laney: I didn't say anything about forbidding on principle, that was infinity :) | 17:48 |
| Laney | I didn't say I was addressing you micahg :P | 17:48 |
| Laney | maybe I was with the CVE comment though ... | 17:48 |
| * Laney runs | 17:48 | |
| micahg | Laney: oh, silly me with my backport highlight :) | 17:48 |
| infinity | backport backport backport | 17:48 |
| infinity | This could be fun. | 17:48 |
| ogra_ | backwards rolling releases ? | 17:49 |
| * Laney eyes the universe page on the CVE tracker | 17:49 | |
| Laney | bad community | 17:49 |
| infinity | No biscuit? | 17:49 |
| micahg | Laney: people in glass houses :) | 17:50 |
| infinity | ... shouldn't walk around naked? | 17:50 |
| ogra_ | depends | 17:50 |
| infinity | ogras in glass houses shouldn't walk around naked? | 17:50 |
| infinity | Anyhow. Back to work with me. | 17:51 |
| infinity | SpamapS: Ping me and keep me in some sort of loop about whatever's going down. | 17:51 |
| infinity | SpamapS: As Laney says, a backport with a firm support commitment would probably be fine, but I don't see the security team agreeing to it, and I suspect your team doesn't want to maintain a precise backport for five years. | 17:51 |
| SpamapS | infinity: I'm going to put 5.4.0 in a PPA and make a call for testing.. and test whatever I can myself. | 17:52 |
| infinity | SpamapS: But. I could be wrong on the latter (I suspect I'm not wrong on the former) | 17:52 |
| micahg | the security team will not be supporting the backport :) | 17:52 |
| SpamapS | infinity: one thing thats going to suck is how many upstreams are not ready for it because it only came out 2 weeks ago. | 17:52 |
| infinity | Most of the "important" ones move pretty fast. | 17:52 |
| mhall119 | seb128: ping | 17:52 |
| * SpamapS is convinced the backport is a bad idea. | 17:52 | |
| infinity | And, as you point out, the one really nasty change has been a deprecated/warning for years. | 17:53 |
| seb128 | mhall119, hey | 17:53 |
| SpamapS | infinity: right, but at this point in the cycle.. shouldn't we be moving.. slow. ;) | 17:53 |
| mhall119 | seb128: your last comment on https://code.launchpad.net/~mhall119/ubuntu/precise/geany/add_keywords/+merge/94825 was talking about quicklist changes, but the MP is for keywords | 17:53 |
| infinity | SpamapS: Yup. I'm just trying to mediate a lesser of multiple weevils in this case. | 17:54 |
| micahg | SpamapS: you have the option to backport PHP later as well if at some point you find testers/people willing to help make sure security updates flow (i.e. build and don't break the old backport) | 17:54 |
| seb128 | mhall119, your upstream pull request link confused me | 17:55 |
| seb128 | mhall119, you have 3 patches there, 2 of them dealing with lists | 17:55 |
| mdeslaur | oh, please, let's not ship an LTS with a .0 PHP release | 17:55 |
| infinity | SpamapS: If enough testing can happen "soonish", my preference is definitely with shipping 5.4.0, and maybe even a short-term (ie: not standing) SRU exception to jam a point release into updates post-release. | 17:55 |
| mdeslaur | trying to maintain that security-wise for the next 5 years will be brutal | 17:55 |
| mhall119 | seb128: one pull request should have been deleted.... | 17:55 |
| mhall119 | I'll go back and check | 17:56 |
| infinity | mdeslaur: And 5.3.x for another 5 years won't be? :) | 17:56 |
| seb128 | mhall119, thanks | 17:56 |
| seb128 | mhall119, otherwise the keyword stuff looks good now | 17:56 |
| mdeslaur | infinity: no, because the code stopped evolving...the thing with .0 releases is everyone then panics and does major changes in .1 and .2 and .3 and then we're stuck with code that's not like the previous stable release, and looks nothing like the current stable release | 17:57 |
| infinity | mdeslaur: PHP vulns seem to be pretty awesome at applying universally all the way back to 4.0 (and sometimes 3.x!) | 17:57 |
| infinity | mdeslaur: I'm told by SpamapS that the release process has "changed". I'm kinda taking his word on that. | 17:57 |
| infinity | mdeslaur: Though, the part where they had eight RCs is a good sign. | 17:57 |
| mdeslaur | infinity: aren't you on the release team? you should be fighting against major last minute changes like this in an LTS, not arguing for them :) | 18:00 |
| infinity | mdeslaur: I'm fighting against shipping a 5.4.0 backport that's unsupported and we know damn well a large number of users will use. | 18:00 |
| mdeslaur | yeah, I don't think we should be doing that either | 18:01 |
| mdeslaur | they can wait until lts+1, or get it from a PPA | 18:01 |
| infinity | mdeslaur: But I too am in the "php dot-zeros suck" camp from my years of maintaining it, which is why I'd be willing to have a post-release temporary SRU exception for a dot release or two. | 18:01 |
| infinity | I just think that is a large enough number of users will be looking elswwhere for PHP (and not the ones that always build it themselves anyway), we need to sort out how to make this the least scary nightmare. | 18:02 |
| mdeslaur | infinity: ah, yeah, that would make more sense then living with .0 for 5 years... | 18:02 |
| infinity | (Other than dropping PHP completely, so don't suggest it) | 18:02 |
| mdeslaur | hehe | 18:03 |
| infinity | But yeah, I think a couple of dot releases would likely solve my concerns and yours. | 18:03 |
| infinity | Assuming 5.4.x is viable at all, which SpamapS will test. | 18:03 |
| infinity | Until that testing's vaguely underway, I don't much care about the other tangents of the conversation anyway. Cause the point may prove moot. | 18:04 |
| infinity | But if it looks really viable, we can make it work. | 18:04 |
| * mdeslaur nods | 18:04 | |
| infinity | We have the flexibility and a little bit of creativity between us. ;) | 18:04 |
| SpamapS | mdeslaur: the PHP release process is *completely* different. No major features or backward incompatible changes are allowed in 5.4 | 18:07 |
| SpamapS | mdeslaur: and they are targetting releaseing 5.5 in *October* | 18:08 |
| SpamapS | mdeslaur: https://wiki.php.net/rfc/releaseprocess | 18:08 |
| SpamapS | "No feature addition after final x.y.0 release (or x.0.0). Self contained features or new SAPIs could be carefully considered on a case by case basis. | 18:09 |
| SpamapS | " | 18:09 |
| SpamapS | mdeslaur: lets not get too far ahead of ourselves, but I think we might even be able to consider a micro release exception | 18:10 |
| SpamapS | *IF* they prove disciplined in sticking to this RFC | 18:10 |
| * mdeslaur crosses fingers | 18:10 | |
| cjwatson | hallyn: so, grub2 is failing its tests for me: it's non-deterministically hanging when trying to halt a qemu instance | 18:15 |
| cjwatson | hallyn: Debian's qemu has got through 20 runs of that test without failing, so I think this is a bug in Ubuntu's qemu. What do you need? | 18:16 |
| hallyn | cjwatson: i have no idea. Since i'm basically out all this week i'm afraid i may have to ask someone else to look at it. But, how do i reproduce? | 18:18 |
| cjwatson | http://people.canonical.com/~cjwatson/tmp/grub-test-build.tar.gz - untar and run for x in `seq 1 100`; do echo "RUN $x"; /bin/sh -e ./grub-shell --qemu-opts= --modules= ./grub_script_break; done | 18:19 |
| cjwatson | (that's actually finished uploading now ...) | 18:20 |
| cjwatson | I can try to decompose this a bit further so that it doesn't need a full build tree | 18:21 |
| hallyn | downloading | 18:21 |
| cjwatson | ok, http://people.canonical.com/~cjwatson/tmp/grub-breaks-qemu.iso, considerably smaller | 18:23 |
| cjwatson | qemu-system-i386 -nographic -serial file:/dev/stdout -monitor file:/dev/null -hda grub-breaks-qemu.iso -boot c | 18:23 |
| cjwatson | should print a load of output and exit; instead, sometimes prints the same load of output and hangs | 18:24 |
| hallyn | cjwatson: http://people.canonical.com/~cjwatson/tmp/grub-breaks-qemu.iso permission denied | 18:26 |
| cjwatson | sorry, fixed | 18:26 |
| === deryck[lunch] is now known as deryck | ||
| hallyn | haven't reproduced it yet, but i wonder if it's a seabios bug | 18:46 |
| cjwatson | hallyn: I'm on an amd64 kernel with i386 userspace, if that matters; but since Debian qemu works and I see the same thing with qemu-system-x86_64, it seems not | 18:54 |
| broder | ScottK, SpamapS, Laney: the TB has approved the policy, but i want to ping them about one tweak. lp needs to be modified in a couple of key ways for us to accept backports when the archive is not frozen/released. and i need to write the bot that tells us when the release pocket might have a change that backports doesn't | 19:11 |
| broder | (i want to tweak the requirement about the components that are enabled for backports builds - TB approved making it the same as the rest of the archive, but i want to nix that given how we ended up deciding to implement it) | 19:12 |
| hallyn | cjwatson: how often would you say it hangs for you? | 19:16 |
| hallyn | i'm doing 64-bit userspace. guess i'll debootstrap a 32-bit userspace and try it in a chroot | 19:18 |
| cjwatson | hallyn: it's a bit sporadic, but somewhere between 10% and 50% of the time | 19:22 |
| cyphermox | jdstrand: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/947416 | 19:42 |
| ubottu | Launchpad bug 947416 in ufw (Ubuntu) "DHCPv6 isn't allowed through" [Undecided,New] | 19:42 |
| jdstrand | cyphermox: thanks! :) | 19:43 |
| cyphermox | np :) | 19:44 |
| cyphermox | it's getting ridiculously late to notice this, but oh well ;) | 19:44 |
| broder | if anybody's got a sec, i'd appreciate a second pair of eyeballs on https://code.launchpad.net/~broder/ubuntu/precise/bluez/bluez-respawn/+merge/95979 | 19:45 |
| broder | i think i got the maintainer scripts right, but i've never been good at the weird corner cases like these | 19:45 |
| hallyn | cjwatson: still not reproduced (in a seq 1 100 on i386 chroot right now, still going) | 19:57 |
| cjwatson | hallyn: huh | 19:58 |
| cjwatson | hallyn: that's bizarre, I saw it first in sbuild where there's definitely no funny business | 19:58 |
| cjwatson | i386 chroot on amd64 install should be completely equivalent | 19:59 |
| hallyn | cjwatson: can you see if you can reproduce it in gdb with qemu-kvm-dbgsym installed? | 19:59 |
| hallyn | cjwatson: oh, when you tried debian's qemu, that was with precise's seabios installed? | 20:00 |
| SpamapS | am I crazy or does my focus seem to just jump around every once in a while while typing in precise? | 20:00 |
| * SpamapS suspects a new obscure keyboard shortcut | 20:00 | |
| hallyn | not your huge-ass trackpad? | 20:00 |
| SpamapS | its 2 feet away from my fingers which are on my USB keyboard ;) | 20:01 |
| lifeless | see | 20:01 |
| lifeless | thats huge ass | 20:01 |
| SpamapS | could be its catching clicks from dust falling in the room | 20:01 |
| hallyn | :) | 20:01 |
| lifeless | if you can hit it from 2ft away | 20:01 |
| hallyn | <chekcs bofh calendar> solar flares | 20:01 |
| * SpamapS does breathe heavily | 20:01 | |
| hallyn | SpamapS: i personally haven't seen anything like that, but then i keep hitting the 'menu' key and getting terminal menu, so might not even notice if it was there | 20:03 |
| hallyn | cjwatson: yeah, 100 runs in i386 chroot, no hangs | 20:07 |
| hallyn | trying to think what coudl be different | 20:07 |
| hallyn | are you on amd? | 20:07 |
| infinity | Host kernel version? | 20:07 |
| hallyn | 3.2.0-17-generic #26 for me | 20:08 |
| imbrandon | SpamapS: i get/got that with my bluetooth mice batterys go low and i get random ghost clicks | 20:09 |
| hallyn | cjwatson: you're running with kvm enabled right? | 20:10 |
| ajmitch | SpamapS: php 5.4.x came up again? I didn't test much beyond merging an RC & seeing what extensions broke because of how the RCs were still coming out | 20:14 |
| imbrandon | ajmitch: its not too bad been running our apps on 5.4 a few weeks in prep | 20:17 |
| imbrandon | ajmitch: even got runkit working :) | 20:18 |
| mhall119 | mvo: I submitted the edit-patch changes upstream too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662689 | 20:34 |
| ubottu | Debian bug 662689 in devscripts "devscripts: [edit-patch] should not unapply quilt patches" [Normal,Open] | 20:34 |
| Daviey | mhall119: Fancy making it not prepend stock (##'d out) DEP-3 headers when there are already valud entries there | 20:36 |
| Daviey | Oh, also make it use DEBEMAIL for Author: field? | 20:37 |
| Daviey | kkthnx | 20:37 |
| mhall119 | Daviey: say what now? | 20:37 |
| Daviey | mhall119: if you edit-patch an existing patch, it'll add stock headers to a patch that already contains valid headers. this sucks. | 20:38 |
| mhall119 | Daviey: I only fixed what I needed fixed, I haven't contributed enough to get stuch with othership :P | 20:39 |
| mhall119 | s/stuch/stuck/ | 20:39 |
| mhall119 | s/othership/ownership/ | 20:39 |
| mhall119 | wow, I need more sleep and/or caffiene | 20:39 |
| Daviey | mhall119: touched-it-last is ownership, :) | 20:40 |
| mhall119 | I thought it was a three-strikes policy | 20:41 |
| Daviey | mhall119: fair enough. :) | 20:42 |
| slangasek | stgraber: as long as you're looking at 946215, could you see if you can figure out bug #946783? The submitter of 946215 seems to allude to a similar problem in his install | 20:43 |
| ubottu | Launchpad bug 946783 in live-build (Ubuntu) "No networking in live-cd " [High,Incomplete] https://launchpad.net/bugs/946783 | 20:43 |
| cjwatson | hallyn: (1) trying gdb; (2) when I tried Debian's qemu, that was in an actual unstable chroot, so Debian's seabios too, but I'll try with precise's seabios; (3) intel core2duo; (4) 3.2.0-17-generic #27; (5) yes, kvm is enabled | 20:43 |
| stgraber | slangasek: ok, I'll have a look. bug 946215 was a casper bug (we were writing /etc/resolv.conf directly instead of using /run/resolvconf/interfaces/casper when resolvconf is around) | 20:44 |
| ubottu | Launchpad bug 946215 in casper (Ubuntu Precise) "12.04 not set nameserver in pxe boot ( resolvconf or dhcp client bug)" [Medium,Triaged] https://launchpad.net/bugs/946215 | 20:44 |
| slangasek | stgraber: yep, saw your comment :) | 20:44 |
| cjwatson | hallyn: Debian's qemu + precise's seabios seems to work fine (I'm assuming Debian's qemu is configured to use it, mind you) | 20:45 |
| stgraber | slangasek: right, just saw your comment in 946783 and indeed the only case where I see this kind of thing being possible is with NETBOOT being set and in that case you definitely don't want NM messing with it | 20:45 |
| slangasek | stgraber: ok. didn't know if there was another package I should have looked at for code that would do this (I looked in casper and live-build) | 20:46 |
| stgraber | slangasek: so if he confirms it's a netboot live session, then it's a duplicate of bug 946215 (assuming his only problem is lack of working DNS) | 20:46 |
| ubottu | Launchpad bug 946215 in casper (Ubuntu Precise) "12.04 not set nameserver in pxe boot ( resolvconf or dhcp client bug)" [Medium,Fix released] https://launchpad.net/bugs/946215 | 20:46 |
| cjwatson | hallyn: similarly, precise's qemu + unstable's seabios still fails - so I don't think this is a seabios bug | 20:46 |
| stgraber | slangasek: I quickly went through all of the initramfs code and casper for the resolv.conf one, the only place I saw messing with /etc/network/interfaces is in casper (23networking) | 20:47 |
| stgraber | well, there are a few other initramfs hooks doing the same kind of thing (like LTSP) but it shouldn't be relevant to that bug | 20:47 |
| slangasek | stgraber: I'm pretty sure he had no networking at all; but I'm waiting for him to respond to my question... he's a local student that was at the global jam yesterday, I'll continue to nag him on IRC | 20:47 |
| stgraber | slangasek: ok. /proc/cmdline would likely be helpful to find exactly what path he's taking at boot time | 20:49 |
| hallyn | cjwatson: ok, thanks, i'll look through the changelogs | 20:49 |
| hallyn | (biab) | 20:50 |
| cjwatson | hallyn: gdb: http://paste.ubuntu.com/870479/ | 20:50 |
| cjwatson | (which aligns with strace, which shows it stuck in a futex) | 20:51 |
| cjwatson | ... maybe I should open a bug at this point ... | 20:51 |
| dupondje | Where can I report typo's on canonical's website ? ;) | 20:52 |
| highvoltage | https://launchpad.net/canonical-web seems appropriate | 20:52 |
| cjwatson | bugs.launchpad.net/canonical-website | 20:52 |
| cjwatson | oh, yes, what highvoltage said, sorry | 20:53 |
| dupondje | that seems more like layout and framework things no? Not really the text itself | 20:54 |
| === dendrobates is now known as dendro-afk | ||
| cjwatson | mdz,pitti: TB? | 20:59 |
| mdz | cjwatson, y | 21:00 |
| Daviey | mdz: wow, you are still alive! | 21:02 |
| mdz | I am! | 21:02 |
| slangasek | TREllis: gconf 3.2.3-2> let me have a look | 21:03 |
| bryceh | heya mdz, long time | 21:08 |
| mdz | bryceh, howdy! | 21:08 |
| cjwatson | scott-work: do you happen to be around? if so, TB in #ubuntu-meeting | 21:09 |
| scott-work | cjwatson: aye | 21:17 |
| SpamapS | ajmitch: it would have been nice to have seen your results reported on the blueprint https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54 | 21:32 |
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| alexbligh | Is there some lazy way for me to spit out all the stuff apport does into a text file, without reporting a bug? (IE does apport invoke one program, or do all the hard work itself) | 23:12 |
| broder | alexbligh: are you looking for apport-unpack? | 23:12 |
| broder | oh sorry, collect the information? you can do that with ubuntu-bug --save=something.crash | 23:13 |
| alexbligh | broder, don't think so. I want to run it on the system with the problem, but not send the system info in via apport / lp | 23:13 |
| broder | (apport does all the collection internally) | 23:13 |
| alexbligh | $ ubuntu-bug --save=x.crash | 23:14 |
| alexbligh | No pending crash reports. Try --help for more information. | 23:14 |
| alexbligh | (note there will have been no crashes - I just want all the system information) | 23:14 |
| broder | you have to give it a package name. apport collects different information based on which package it's reporting a bug against | 23:15 |
| broder | see ubuntu-bug --help | 23:15 |
| alexbligh | broder, oh sure, so apport-bug linux --save=blah. But I don't want to report against a package, as I don't want it to ask me questions (it's in an automated script gathering system info), I just want it to do the system info bit. | 23:17 |
| broder | alexbligh: i don't know of any way to do that | 23:17 |
| alexbligh | broder, thx - I will just have to be less lazy and do it myself... | 23:19 |
| cjwatson | hallyn: I filed this as bug 947597 | 23:40 |
| ubottu | Launchpad bug 947597 in qemu-kvm (Ubuntu) "qemu sometimes hangs on shutdown in GRUB tests" [Undecided,New] https://launchpad.net/bugs/947597 | 23:40 |
| === dendro-afk is now known as dendrobates | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!