| poolie | is there any way to have apport still save a core file in to your pwd? | 00:31 |
|---|---|---|
| RAOF | ogra_: I see that armhf doesn't have any of the arm-specific X video drivers; is this intentional? | 00:40 |
| infinity | RAOF: Example? | 00:46 |
| infinity | RAOF: And if it's just a case of someone doing s/armel/armel armhf/ in debian/control, feel free. | 00:46 |
| RAOF | infinity: omapfb, tegra, msm. | 00:47 |
| infinity | RAOF: (And no, it's not currently intentional for anything on armel to not be also on armhf) | 00:47 |
| infinity | RAOF: Oh, except tegra, which is a binary blob. | 00:48 |
| RAOF | Right. | 00:48 |
| infinity | RAOF: But anything that's actually free software (which I assume omapfb is?) should be compiled on armhf, yes. | 00:48 |
| RAOF | I suspected as such. | 00:48 |
| RAOF | Ok. | 00:48 |
| RAOF | Yeah, omapfb is. | 00:49 |
| RAOF | Hm. Is there a grep-dctrl rune for selecting packages which Depend on xorg-video-abi-10 *and* are only built on armel? | 01:12 |
| RAOF | I take it no one cares too much about omapfb? Does anyone care if it uses softfloat an armhf? | 01:36 |
| infinity | RAOF: Err, what? | 02:01 |
| infinity | RAOF: If it uses the softfp ABI, it won't work on armhf. | 02:01 |
| RAOF | That's not obvious to me. Good to know! | 02:02 |
| RAOF | Anyway, turns out that what we actually want to do is sync from debian. | 02:02 |
| infinity | What's the package name in question? | 02:02 |
| RAOF | xf86-video-omapfb | 02:03 |
| RAOF | Currently it's not built for armhf; a sync from Debian includes all our changes and adds armhf to the list of architectures as an added bonus. | 02:03 |
| infinity | It... Does? | 02:03 |
| infinity | packages.qa disagrees... Maybe it's lagging. | 02:04 |
| RAOF | http://anonscm.debian.org/gitweb/?p=collab-maint/xf86-video-omapfb.git;a=blob;f=debian/control;h=66ec8b102e36c13a766f87bb2aca30bb44b86773;hb=012d94a229e639317a79fa3ad1eadc27d4f75b5a | 02:04 |
| RAOF | Unless the tag lies, of course. | 02:05 |
| infinity | Oh, indeed. I was misreading something, based on the date. | 02:06 |
| infinity | Wow, that new device "detection" (and I use that term loosely) code is vile. | 02:13 |
| infinity | RAOF: But yes, syncing it looks like the right thing to do. | 02:14 |
| infinity | RAOF: (Pressing the button) | 02:14 |
| RAOF | You don't need to. | 02:14 |
| infinity | Too late? :) | 02:15 |
| RAOF | Heh. 'scool. It's staged in the Xserver 1.11 staging PPA with a -build1 version anyway :) | 02:15 |
| infinity | Oh. That seems silly. | 02:16 |
| infinity | But okay. | 02:16 |
| infinity | And I'm guessing -msm can just have debian/control mangled for great justice. | 02:16 |
| RAOF | Well, I don't think I can sync to the PPA and we want to copy everything at once so we don't have archive-skew. | 02:16 |
| infinity | Don't see why you wouldn't be able to copy from debian to a PPA. | 02:17 |
| infinity | Though I've never tried. | 02:17 |
| RAOF | I don't know where the button is. | 02:17 |
| micahg | soren has a script for that I think | 02:17 |
| infinity | Well, it wouldn't require a script, per se. | 02:17 |
| infinity | Though, if you were scripting, you could sync-package --no-lp, and then upload to your PPA instead of the archive. | 02:17 |
| infinity | Which would actually make it look like a sync. | 02:18 |
| infinity | But. | 02:18 |
| infinity | Just copying the sources would be fine too. | 02:18 |
| infinity | Since no one gives a crap about what the .changes in a PPA look like. | 02:18 |
| micahg | a script could do it w/out transversing your machine though | 02:18 |
| infinity | micahg: I'm not convinced the web UI can't do it, though I haven't looked. | 02:18 |
| * infinity looks. | 02:19 | |
| RAOF | I don't think you actually *can* sync-package --no-lp; the PPA will reject the upload if it's aimed at unstable, right? | 02:20 |
| cjwatson | syncpackage --no-lp will fiddle with Distribution in .changes. | 02:20 |
| infinity | ^ | 02:20 |
| infinity | It's the target in .changes that matters, not the one in the changelog. | 02:20 |
| cjwatson | syncpackage without --no-lp can't copy to PPAs yet | 02:21 |
| cjwatson | see Archive._checkCopyPackageFeatureFlags in LP | 02:21 |
| cjwatson | # We have no way of giving feedback about failed jobs yet, | 02:22 |
| cjwatson | # so this is disabled for now. | 02:22 |
| RAOF | infinity: https://launchpadlibrarian.net/90400263/buildlog_ubuntu-precise-armhf.xf86-video-msm_1.0.1%2Bgit20100122.5f7df591-1ubuntu1_FAILEDTOBUILD.txt.gz is a FTBFS of mxm on armhf. It looks like a toolchain issue, maybe? | 02:23 |
| infinity | RAOF: Multiarch sadness. | 02:23 |
| RAOF | Hm. Execpt perhaps for the bit where it goes -march=armv7-a -mfpu=neon -mfloat-abi=softfp | 02:24 |
| micahg | umm, I'm curious about the recent uploads limiting the arch, most of them seem to make more sense as p-a-s since it's stuff they build on that's limited | 02:24 |
| infinity | RAOF: That's also bad. :P | 02:24 |
| infinity | RAOF: Should be -mfloat-abi=hard (or not have the flag at all, since our compilers on armel and armhf get it right) | 02:24 |
| infinity | micahg: Which recent uploads? | 02:25 |
| infinity | Oh, indi-sbig? | 02:25 |
| micahg | https://launchpad.net/ubuntu/precise/+source/indi-sbig/1.0-0ubuntu2, https://launchpad.net/ubuntu/precise/+source/crystalspace-glshader-cg/1.4.0-1ubuntu1 | 02:25 |
| infinity | micahg: If it depends on some binary blob or something (which I guess is the case in the crystalspace one?), setting the arch in control seems reasonable. | 02:27 |
| infinity | It's not arch-specific because it "needs porting", it can't be ported. | 02:27 |
| infinity | micahg: Same deal for the other one, it would seem. | 02:28 |
| RAOF | Aww, that's so cute. Hardcoding CFLAGS in Makefile.am | 02:29 |
| infinity | Speaking of porting, do I trust this fpc_armhf binary I just built? | 02:29 |
| micahg | yeah, I was thinking along of lines of if the thing itself isn't arch specific, just the dependency, that might change over time | 02:29 |
| infinity | micahg: Sure, but if the dep changes, you're editing control anyway. | 02:29 |
| infinity | micahg: So, you can fix the arches. :P | 02:29 |
| infinity | micahg: Which is, actually, way less hassle than P-a-s. | 02:29 |
| cjwatson | argh | 02:30 |
| * cjwatson introduces gnome-games to Replaces | 02:31 | |
| infinity | fpc uncleverly compiles everything statically, doesn't it? | 02:31 |
| infinity | Which means a new upstream version doesn't require a transition... | 02:31 |
| infinity | Hrm. | 02:31 |
| * infinity decides to take his newly-built 2.4.4/armhf binary and use it to bootstrap 2.6.0 and see how that goes. | 02:32 | |
| * RAOF decides that's enough arm faffing and goes to have some lunch. | 02:36 | |
| cjwatson | Could somebody on a more appropriate timezone than me please update ubuntu-meta after this publisher run finishes, such that it removes gnome-mahjongg and adds mahjongg? It shouldn't be more than about 15 minutes from now until archive.u.c updates, but I really need to crash. | 02:54 |
| cjwatson | And this will fix tomorrow morning's CD builds, not to mention the ARM failures that are coming in now. | 02:54 |
| infinity | cjwatson: Can do. | 02:55 |
| cjwatson | Ta | 02:55 |
| cjwatson | I'm doing xubuntu-meta now since that doesn't need mahjongg to be in main | 02:55 |
| cjwatson | Argh, xubuntu-meta fell over with a Packages validation error | 03:02 |
| cjwatson | infinity: Would you mind doing xubuntu-meta as well? | 03:02 |
| cjwatson | One of these days I'll make germinate more robust against that and have it brutally retry everything without caching on hash mismatches or something ... | 03:03 |
| micahg | I can take care of xubuntu-meta | 03:03 |
| micahg | unless infinity wants to do it that is | 03:04 |
| SpamapS | woot, my touchpad works | 03:11 |
| SpamapS | stock precise seems to work perfectly on the MBA 4,1 .. yay | 03:11 |
| mwhudson | SpamapS: QUICK RELEASE | 03:12 |
| * SpamapS looks at the greybeards guarding the release levers and wonders if he can get past them before they cast Great Fireball to incinerate him | 03:14 | |
| infinity | cjwatson: I can do both. | 03:16 |
| infinity | micahg: ^ | 03:16 |
| infinity | SpamapS: My beard's not that grey... :( | 03:18 |
| pitti | Good morning | 05:35 |
| === bladernr_ is now known as bladernr_afk | ||
| pitti | jibel: I updated https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-lts-upgrades with a link to the gdm->lightdm migration test; it uses python unittest, I believe that's an output format you can handle? | 07:12 |
| pitti | jibel: it has a header which explains the details; please let me know if you need it to do something different | 07:13 |
| jibel | pitti, good morning | 07:37 |
| pitti | jibel: bonjour Monsieur, ca va? | 07:37 |
| jibel | pitti, très bien et toi ? | 07:37 |
| pitti | jibel: je sui bien, merci! | 07:38 |
| pitti | jibel: working on user config migration test right now | 07:38 |
| jibel | pitti, thanks for the script, I'll add it to the upgrade test today. | 07:38 |
| pitti | jibel: trying to remember which other popular settings we mentioned, besides background image | 07:38 |
| pitti | jibel: for the system one it's sufficient to run it after upgrade | 07:39 |
| pitti | jibel: for the user one, we need a "prepare" shell script to run in the lucid environment; will that be possible? | 07:39 |
| jibel | pitti, yes it will. we can run a script right after the initial bootstrap to prepare the environment | 07:40 |
| pitti | jibel: i. e. the prepare script wiggles the old settings (gconf/custom launchers), then you upgrade, and the test_lts_upgrade_user.py script will then check what the new gsettings/launchers are | 07:40 |
| jibel | pitti, I added support to catch debconf prompts yesterday | 07:41 |
| jibel | pitti, here is an example https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lts/PROFILE=lts-server,alderamin-upgrade=alderamin-upgrade/12/artifact/lts-server/ | 07:41 |
| pitti | jibel: yay, with the fake editor trick? | 07:41 |
| pitti | jibel: ah, you both have a full log, and some "known good/bad" parts of it? | 07:42 |
| jibel | pitti, right. It was trickier than expected because the noninteractive frontend overrided the frontend. | 07:42 |
| jibel | pitti, I collect the full log then split it in pieces for each /unexpected/ prompt | 07:43 |
| pitti | jibel: ah, so you have to monkey-patch upgrade-manager for this? :) | 07:43 |
| jibel | pitti, there is also a whitelist for prompts we'd like to see anyway. | 07:43 |
| jibel | pitti, the node on which lts tests runs uses update-manager form bzr and I proposed a patch | 07:44 |
| jibel | *from | 07:44 |
| pitti | jibel: ah; I guess it's enough to not touch it if the environment already has it set? | 07:47 |
| jibel | pitti, yes, that's the patch. | 07:48 |
| pitti | jibel: do you remember anything else except background image and custom launchers? | 07:50 |
| dholbach | good morning | 07:50 |
| pitti | jibel: oh, screensaver settings | 07:51 |
| pitti | jibel: e. g. lock/nolock and the timeout | 07:51 |
| pitti | jibel: .. and I'll set the Radiance theme and check that this is maintained | 07:52 |
| pitti | didrocks: ISTR that unity migrates the old panel launchers, does it? I'd like to add it to my LTS upgrade test script | 08:00 |
| didrocks | pitti: yeah, it migrates: icons in the panel launcher as well the ones on the desktop | 08:01 |
| didrocks | it tries to merge them as well | 08:01 |
| didrocks | (I think we don't want to test migrating from cairo-dock, awn, and other docks that it supports too) | 08:01 |
| pitti | so I'll try four cases: launcher dragged from app menu to panel (pointing to system .desktop), custom launcher in panel, custom desktop icon, and system desktop icon link | 08:02 |
| didrocks | yeah, sounds right | 08:03 |
| === smb` is now known as smb | ||
| jibel | pitti, I have just 'popular settings we'd like to preserve' on my notes, and also launcher, lightdm/gdm (autologin), language/keyboard, nm (needs to be tested on hw for wifi), proprietary drivers | 08:12 |
| jibel | pitti, we could also check that proxy and a11y settings are preserved | 08:12 |
| pitti | jibel: language requires some extra discussion (will ping you again when I did the other stuff), nm pretty much tests itself (do the upgrade over wifi) | 08:15 |
| pitti | jibel: proprietary drivers is not on my todo list, right? | 08:15 |
| jibel | pitti, no it is not and it also needs hw which can't be tested with the auto upgrade tester. I'll see what I can do with the hw available in the lab and cobbler/orchestra. | 08:20 |
| mvo | slangasek: next issue with the new apt, the debian dpkg wants to be configured using pkgname:arch but our dpkg does not understand that yet so it leaves the pkgs unconfigure *sigh* | 08:26 |
| === Quintasan_ is now known as Quintasan | ||
| pitti | didrocks: got the test cases for app/custom panel starter now, both work; but why would custom .desktop files on the desktop go into the launcher, and not stay on the desktop? | 09:31 |
| didrocks | pitti: this was a design request: everything, even on the desktop, should go to the launcher so that people can remove them from the desktop | 09:31 |
| pitti | hmkay | 09:32 |
| didrocks | pitti: I know it irritated some people at the time, maybe we should check back with John, it was at the time we didn't "show desktop" IIRC | 09:32 |
| didrocks | (on UNE) | 09:32 |
| pitti | didrocks: let me try it, and I'll add it to the test cases | 09:33 |
| pitti | didrocks: if we decide that it shouldn't happen, it's a good negative test case, and we can just flip assertTrue to assertFalse :) | 09:33 |
| didrocks | pitti: indeed :) | 09:33 |
| didrocks | (changing that will take me 10s FYI in the migration script), so just need to take the time to talk to John | 09:33 |
| pitti | didrocks: oh, so it actually copies the .desktop file to someplace else then? | 09:35 |
| pitti | didrocks: for the panel launchers it just keeps the ones in .gnome2/panel/... | 09:36 |
| didrocks | pitti: I need to refresh my memory, one moment | 09:36 |
| pitti | didrocks: if you don't move them, then they'd just stay on teh Desktop, and if you remove them from Desktop/, they'd break from the launcher as well? | 09:36 |
| didrocks | pitti: yeah, was definitively at the time we used UNE and didn't show desktop | 09:38 |
| didrocks | pitti: so, they are not copied, which seems indeed useless right now | 09:38 |
| didrocks | pitti: I'll catch this up with John :) | 09:39 |
| pitti | didrocks: merci | 09:39 |
| didrocks | pitti: thinking about that, we need to handle the transition from UNE 10.04 -> ubuntu 12.04 | 09:39 |
| didrocks | pitti: it should import the favorites from netbook-launcher | 09:39 |
| pitti | didrocks: ah, indeed | 09:39 |
| didrocks | pitti: de rien :) | 09:39 |
| pitti | sounds like a nice additional test case, too | 09:39 |
| didrocks | indeed | 09:40 |
| pitti | didrocks: ah, it's clever enough to just say "gucharmap.desktop" | 09:45 |
| pitti | didrocks: instead of Desktop/gucharmap.desktop" | 09:45 |
| pitti | didrocks: so that part technically works, although it's looking strange | 09:45 |
| pitti | so I'll do add a totally custom launcher, too | 09:45 |
| didrocks | pitti: yeah, I have a quite long algorithm to try to prefer system ones | 09:45 |
| didrocks | matching on desktop name, then on exec key name… | 09:46 |
| jamespage | morning: can someone help me with this package build failure | 09:46 |
| jamespage | https://launchpadlibrarian.net/90422989/buildlog_ubuntu-precise-armel.hadoop_0.20.205.0-0ubuntu1~hadoop4_FAILEDTOBUILD.txt.gz | 09:46 |
| didrocks | that's what I meant by "merging the launcher" | 09:46 |
| didrocks | (and why you don't have two firefox.desktop launcher icons) | 09:46 |
| jamespage | package build fine on the other four architectures and on some armel builds; dpkg-shlibdeps is doing something weird | 09:47 |
| jamespage | builds just fine on my local armel install :-( | 09:47 |
| pitti | didrocks: ok, got all four covered now | 09:52 |
| didrocks | excellent! thanks pitti :) | 09:52 |
| pitti | didrocks: avec plaisir! | 09:52 |
| fijal | hi | 10:27 |
| fijal | I think I managed to crash unity up to the point where it does not start even | 10:28 |
| fijal | how can I find out what's going on? | 10:28 |
| fijal | is there any log, can I run debug mode? | 10:28 |
| tumbleweed | fijal: .xsession-errors? | 10:33 |
| fijal | where? | 10:34 |
| fijal | in . | 10:34 |
| fijal | ? | 10:34 |
| fijal | er | 10:34 |
| tumbleweed | in ~ | 10:34 |
| fijal | in ~ | 10:34 |
| fijal | (unity-window-decorator:2146): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed | 10:34 |
| fijal | I'm kind of used to that CRITICAL | 10:34 |
| tumbleweed | you'll see lots of thnigs like that | 10:34 |
| tumbleweed | also, this isn't really a support channel, but if you want to get it back to a sane state: unity --reset | 10:35 |
| tumbleweed | barry: I see your i386 pypy PPA build didn't have enough RAM. Retry it and hope that we have bigger PPA builders available? | 10:36 |
| fijal | tumbleweed: I know this is not a support channel, but I'm trading priority support for priority support I guess :) | 10:37 |
| pitti | jibel: I have the user settings part ready now as well, BP updated | 10:55 |
| === _salem is now known as salem_ | ||
| micahg | pitti: can you please copy ubufox/lucid to lucid-proposed and ubufox/maverick to maverick-proposed from ubuntu-security-proposed? | 11:54 |
| barry | tumbleweed: saw that, will do! | 12:13 |
| === MacSlow is now known as MacSlow|lunch | ||
| pitti | micahg: oh, just ubufox, not firefox and the langpacks? | 12:47 |
| pitti | micahg: oh, nevermind, misread | 12:48 |
| pitti | micahg: sure | 12:48 |
| pitti | micahg: done | 12:51 |
| micahg | pitti: thanks | 13:12 |
| slangasek | mvo: hmm, lovely :P | 13:20 |
| mvo | slangasek: the unstoppable david worked it out in the end | 13:20 |
| slangasek | ok :) | 13:20 |
| mvo | preparing a version (again!) | 13:21 |
| cjwatson | mvo: is there a particular reason there's no DistUpgrade.cfg.precise in update-manager yet? | 13:24 |
| cjwatson | was just looking for how it handled the removal of the transitively-essential lzma, and couldn't find anything | 13:24 |
| cjwatson | oh, looks like update-manager doesn't have the same transitively-essential handling that apt itself does | 13:25 |
| cjwatson | so I guess it wouldn't run into that | 13:25 |
| mterry | @pilot in | 13:27 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry | ||
| === udienz_ is now known as udienz | ||
| === bladernr_afk is now known as bladernr_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| dholbach | hey barry - with http://blog.bazaar.canonical.com/?p=405 do we have to fix/change our docs? | 14:15 |
| Laney | ooh, those are exciting fixes | 14:16 |
| smoser | in ec2 instances, i get errors to the console on boot of 'mountall: Event failed' | 14:18 |
| smoser | that seems to generally be not a problem, but I'm wondering if anyone would know the source of that message. | 14:19 |
| smoser | i see it on all boots, not just the first (when cloud-init is admittedly playing funny as it updates /etc/fstab on mounted /) | 14:19 |
| slangasek | cyphermox: hey there | 14:23 |
| barry | dholbach: we will :) | 14:26 |
| cyphermox | slangasek: hey | 14:27 |
| cyphermox | is this about bluez? | 14:27 |
| slangasek | cyphermox: yeah ;) hold that thought, I'm just getting upgraded from -0ubuntu1 to -0ubuntu3 | 14:27 |
| slangasek | (dunno why update-manager hadn't told me about it yet) | 14:28 |
| cyphermox | yeah, it was majorly messed up, sorry | 14:28 |
| slangasek | cyphermox: so, after upgrading from -1 to -3, I see the following problems so far: | 14:30 |
| slangasek | - bluetooth-daemon service is still running and can't be stopped (because the job file no longer exists) | 14:30 |
| slangasek | - /etc/init/bluetooth-daemon.conf.dpkg-backup is left behind even though I never modified this file | 14:30 |
| cyphermox | hm | 14:31 |
| slangasek | - package is considered successfully installed even though 'bluetooth' job hasn't been started | 14:31 |
| cyphermox | slangasek: the big issue was that -0ubuntu1 really, because if you upgrade straight from 4.96-* things work out properly | 14:31 |
| * cjwatson spies a pending libwmf merge that should take care of this messy upgrade bug | 14:32 | |
| slangasek | cyphermox: and the big issue: pulseaudio still doesn't see my headset | 14:32 |
| cyphermox | I tried to fix the crap that was there, but I see it didn' t work out -- weird because I tested upgrading between the 4.96-* version and from 4.98-0ubuntu1 before uploading | 14:32 |
| slangasek | (after manually shuffling jobs) | 14:32 |
| cyphermox | slangasek: rebooting would help | 14:32 |
| slangasek | not acceptable ;) | 14:33 |
| cyphermox | slangasek: I know ;) initctl list | grep bluetooth ? | 14:33 |
| slangasek | $ sudo initctl list | grep bluetooth | 14:33 |
| slangasek | bluetooth start/running, process 27296 | 14:33 |
| slangasek | bluetooth-device (hci0:12) start/running | 14:33 |
| cyphermox | ah? | 14:33 |
| slangasek | also, why are we trying to start/stop bluetoothd on device add/remove *anyway*? | 14:33 |
| cyphermox | but was your headset ever paired? let me get mine and test it on this system I just upgraded | 14:33 |
| slangasek | what do you mean, "ever paired"? it's been working for a solid year | 14:34 |
| slangasek | this is a regression | 14:34 |
| slangasek | if I restart pulseaudio, I can now see it listed in 'hardware', but not available in the input/output list | 14:35 |
| slangasek | (under gnome-control-center sound) | 14:35 |
| slangasek | and pulseaudio didn't get upgraded, only bluez | 14:35 |
| cyphermox | slangasek: what I mean is, I' m trying to understand why it doesn' t work for you, when I precisely tested that on my own system, from either the very old version or the broken 4.98-0ubutnu1, and things *were* working | 14:35 |
| dholbach | barry, should I file a bug about it? | 14:36 |
| cyphermox | slangasek: ah, what profile is used for your headset? | 14:38 |
| cyphermox | slangasek: A2DP? | 14:38 |
| slangasek | cyphermox: I use both a2dp and hsp/hfp profiles; it looks like the sink is only missing in the a2dp profile | 14:39 |
| cyphermox | slangasek: right, I see that too | 14:39 |
| slangasek | cyphermox: ok. should I file a bug report? | 14:39 |
| cyphermox | please | 14:40 |
| doko | \o/ notebook working again ... | 14:40 |
| cyphermox | that's indeed a regression from 4.96, though it's better than what state 4.97 was in :) | 14:40 |
| cyphermox | slangasek: any help with fixing up that upstart job mess would be welcome | 14:40 |
| cyphermox | slangasek: the whole point of the upstart jobs was to avoid having bluetoothd running when you don' t have bluetooth devices though | 14:41 |
| slangasek | why is that worthwhile? | 14:41 |
| slangasek | unused daemons are cheap | 14:41 |
| cyphermox | but why keep it running when it' s not necessary | 14:42 |
| dobey | it makes up for the ones in use that are expensive | 14:47 |
| cyphermox | dobey: meh | 14:47 |
| dobey | heh | 14:47 |
| dobey | and there's no need to run things that aren't needed | 14:47 |
| dobey | saves resources, and energy, to not have them running | 14:48 |
| dobey | however miniscule the change is. but 2 million people using 0.01W less is a lot across the board | 14:48 |
| slangasek | no, it doesn't | 14:49 |
| slangasek | properly-written daemons don't wake up when not needed | 14:50 |
| dobey | they still occupy N bytes of memory, which requires electricity | 14:51 |
| slangasek | the memory is all powered regardless | 14:51 |
| slangasek | this is a false optimization | 14:51 |
| pitti | cyphermox: ^ pretty much what we discussed last week already, AFAIK; I think having an upstart rule to auto-shutdown bluezd is an interesting intellectual exercise, but the main point is to power down the _device_ if you disable it | 14:51 |
| cjwatson | this was once parodied as "zeroes use less power than ones" | 14:51 |
| slangasek | the only time it matters is if you have memory pressure on the machine | 14:51 |
| pitti | keeping the daemon running actually helps to avoid cycles the next time you need it again | 14:52 |
| slangasek | but you probably have firefox running, so bluetoothd is lost in the noise :P | 14:52 |
| pitti | I do agree that bluezd should not start up until you actually have a bluetooth device (or the killswitch on) | 14:52 |
| pitti | cjwatson: that was from the pre-CMOS time? | 14:54 |
| pitti | (when it probably was quite true) | 14:54 |
| seb128 | well running process might not use cpu but they use memory | 14:54 |
| seb128 | not to mention they take time to start so slow boot | 14:55 |
| cjwatson | pitti: nope, Ubuntu era | 14:55 |
| slangasek | on-demand starting of bluetoothd seems fine, sure | 14:55 |
| slangasek | but the stopping is really unnecessary | 14:55 |
| pitti | seb128: right, speaking of automatic shutdown | 14:55 |
| slangasek | (and probably racy, for that matter) | 14:55 |
| stgraber | pitti: I wouldn't mind bluetoothd not being stopped by upstart if soft kill switch was persistent across reboot. I use bluetooth maybe once a year on this machine and I don't have a separate hardware kill switch for bluetooth (except turning it entirely off in the bios ...) | 14:56 |
| pitti | cjwatson: reminds me of "investigate power difference between black or white screen (even for DPMS off)" | 14:56 |
| slangasek | pitti: that one was investigated and did show power savings ;) | 14:56 |
| pitti | stgraber: yes, cyphermox was looking into making the enable/disable persistent across reboots | 14:56 |
| pitti | slangasek: right | 14:56 |
| diwic | slangasek, right, but it was the white screen (surprisingly!) that was most power efficient? | 14:57 |
| stgraber | pitti: that was at the gnome level though so bluetoothd will always start, then the adapter wil lbe turned off when I login but the daemon will still run | 14:57 |
| dobey | diwic: on an LCD, yes. | 14:57 |
| pitti | slangasek: but I wonder when someone actually measured power consuption with all (free) memory set to 0 or 1 :) | 14:57 |
| slangasek | stgraber: the soft kill switch needs to be persistent *regardless*, and stopping the daemon doesn't help with that at all | 14:57 |
| cyphermox | seb128: pitti: not simple, unfortunately, since upstream decided gnome-bluetooth was not the right place to do this. | 14:57 |
| dobey | but not surprising at all | 14:57 |
| pitti | dobey: it is surprising as it said "even with dpms off", i. e with the screen being powered down | 14:57 |
| pitti | cyphermox: *nod*; but at least I think we all agree that it's generally a good idea | 14:59 |
| dobey | pitti: dpms on an LCD doesn't exactly power the screen down though | 14:59 |
| dobey | at least not in the same way it does on a crt | 15:00 |
| stgraber | cyphermox: if I was to make soft kill persistent across reboot would that work for you (rather than patching gnome-bluetooth and do it at the session level)? | 15:00 |
| dobey | i want an oled screen, but nobody makes any with a good resolution :( | 15:00 |
| stgraber | slangasek, cyphermox: Sounds like we just need to dump /sys/class/rfkill/*/soft and restore at boot time | 15:01 |
| slangasek | that would be nice | 15:01 |
| cyphermox | stgraber: yeah, sure | 15:01 |
| cyphermox | I mean, everybody would probably be quite happy about it :) | 15:01 |
| stgraber | (probably checking it's the same device too :)) | 15:01 |
| stgraber | k, will do it later today then, should be pretty easy to do with a simple upstart job | 15:01 |
| dobey | anyway, i was talking about the fact that not starting it in the first place would save power. shutting down an idle running (proper) daemon will probably use more power than it does to sit there and not do anything | 15:03 |
| slangasek | yep | 15:04 |
| cjwatson | http://paste.ubuntu.com/809717/ - anyone object to the creative solution of sticking a no-op prerm in the new libwmf0.2-7? | 15:10 |
| slangasek | isn't that the standard workaround? :) | 15:12 |
| cjwatson | I hadn't encountered it before | 15:12 |
| slangasek | ah... I have | 15:13 |
| slangasek | anyway, no objection :) | 15:13 |
| cjwatson | where, out of curiosity? | 15:15 |
| slangasek | hmm, been a while since I've run into it actually | 15:15 |
| slangasek | so probably nowhere readily discoverable | 15:15 |
| * cjwatson notices that policy does actually have some careful wording about this nowadays | 15:16 | |
| cjwatson | All package dependencies will at least be "Half-Installed" and will have previously been configured and not removed. If there was no error, all dependencies will at least be unpacked, but these actions may be called in various error states where dependencies are only "Half-Installed" due to a partial upgrade. | 15:16 |
| cjwatson | so you can at least deduce the possibility of this class of problem from the documentation if you think about it | 15:17 |
| * cjwatson ponders the feasibility of auditing for this | 15:17 | |
| BenC | doko: Any ideas on the ghc assembler errors on powerpc that is causing, for example, haskell-hashtables to fail to build? | 15:18 |
| BenC | https://launchpadlibrarian.net/87619504/buildlog_ubuntu-precise-powerpc.haskell-hashtables_1.0.0.0-1build1_FAILEDTOBUILD.txt.gz | 15:19 |
| doko | BenC, sorry, no. did it build before, or in Debian? | 15:22 |
| * doko reboots | 15:22 | |
| BenC | doko: no idea, just getting into it | 15:22 |
| BenC | doko: doesn't exist on ubuntu-ppc | 15:23 |
| BenC | hrrm…guess I assumed doko was using screen | 15:23 |
| stgraber | slangasek, cyphermox: http://paste.ubuntu.com/809739/ (rfkill-store.conf) and http://paste.ubuntu.com/809740/ (rfkill-restore.conf) | 15:31 |
| slangasek | stgraber: is the name guaranteed to be whitespace-clean? | 15:32 |
| BenC | doko: it doesn't appear to have ever built on ubuntu at least | 15:35 |
| BenC | ubuntu-powerpc that is | 15:35 |
| doko | BenC, good =) | 15:35 |
| doko | Laney, ^^^ | 15:35 |
| * Laney perks up | 15:35 | |
| Laney | ah, yeah, I meant to raise that. It fails the same way on Debian. | 15:36 |
| stgraber | slangasek: I can't find a clear definition of it in the kernel documentation other than it being a kernel device name which AFAIK can't contain spaces (I'd expect a lot of the userspace to break if they could) | 15:36 |
| slangasek | stgraber: ok - looks fine to me then | 15:36 |
| Laney | if you're brave you can pass -keep-s-files to see what's going on | 15:36 |
| slangasek | stgraber: which package will own this? rfkill itself? | 15:36 |
| BenC | Laney: I did that | 15:36 |
| Laney | and another interesting thing would be to try building with ghc from experimental | 15:36 |
| slangasek | stgraber: oh, shouldn't this be 'start on runlevel [016]' instead of 'runlevel [!2345]'? I don't see any reason to save when switching to single user mode | 15:37 |
| BenC | Laney: srwi 3, 4, 32 | 15:37 |
| stgraber | slangasek: yeah, I'd make it part of rfkill even though it doesn't depend on the rfkill tool itself | 15:37 |
| BenC | Laney: that's the 32 that it claims is out of range | 15:37 |
| Laney | failing that I believe Erik de Castro Lopo in pkg-haskell is interested in ppc issues | 15:37 |
| stgraber | slangasek: oh, correct indeed. I based it on alsa-store but [016] is indeed better | 15:37 |
| Laney | d-haskell@ is a good venue | 15:37 |
| BenC | Ok, thanks | 15:37 |
| slangasek | stgraber: cool - thanks for taking care of this | 15:38 |
| stgraber | np. It's been annoying me for a while (on plane for both wireless + bluetooth and for bluetooth the rest of the time), good to have that fixed for 12.04 | 15:38 |
| Laney | BenC: powerpc is a community supported arch as far as GHC upstream are concerned, with all that that implies | 15:39 |
| slangasek | stgraber: on plane you should be using the hardware switch! :) | 15:39 |
| stgraber | slangasek: indeed :) | 15:41 |
| slangasek | mvo: do you remember what this workitem for lts-upgrades means?: "grep maintainer scripts for dpkg --compare-versions" | 15:41 |
| mvo | slangasek: that was to ensure that compat fixups don't get dropped because its no longer relevant for debian but it is for us | 15:42 |
| BenC | Laney: I'm not familiar with ghc…does it actually emit the assembler or go through gcc somehow? | 15:42 |
| === dendrobates is now known as dendro-afk | ||
| BenC | IOW, where does the blame lie? | 15:42 |
| slangasek | mvo: so which maintainer scripts are supposed to be grepped? | 15:42 |
| mvo | slangasek: compat fixes in the maintainer scripts, so we would have to build a map of what version are in lucid and try to find out if between lucid and precise maintainer scripts with compat code get dropped | 15:43 |
| mvo | slangasek: ideally all I would assume | 15:43 |
| mvo | slangasek: but thats obviously a bit of work | 15:43 |
| slangasek | mvo: I guess I still don't follow... do you need to look at the maintainer scripts for all binary packages uploaded between lucid and precise? | 15:44 |
| slangasek | jibel: your recent edit of foundations-p-lts-upgrades whiteboard has added a line that doesn't seem to be a workitem at all? "It doesn't improve performance because virtual disks are setup to dynamic resizing [...]" | 15:45 |
| mvo | slangasek: this is what I remember from the discussion, yes | 15:46 |
| mvo | (from the UDS discussion) | 15:46 |
| slangasek | mvo: ok - let me expand that description so it's clearer then, thanks | 15:46 |
| slangasek | mvo: do you think we need to inspect just the versions shipped with each intervening release, or all uploads to Ubuntu, or all uploads to Ubuntu *or* to Debian? | 15:46 |
| === dendro-afk is now known as dendrobates | ||
| Laney | BenC: Both. I believe that powerpc is built "registerised" which means that it uses GHC's native code generator. You can check with `ghc --info' | 15:49 |
| jibel | slangasek, that's a comment to explain why it's done but doesn't improve performances. I'll move it to the bottom of the bp. | 15:49 |
| Laney | we should investigate using the LLVM backend more | 15:49 |
| slangasek | jibel: what doesn't improve performance? eatmydata? | 15:50 |
| BenC | Laney: ,("Unregisterised","NO") | 15:50 |
| Laney | BenC: "Have native code generator"? | 15:50 |
| BenC | Laney: Yes for native and llvm | 15:50 |
| cjwatson | jibel: How do I see what commands were run as part of https://jenkins.qa.ubuntu.com/job/precise-upgrade-lts/PROFILE=lts-main-all,alderamin-upgrade=alderamin-upgrade/lastFailedBuild/ ? "View Configuration" shows nothing | 15:51 |
| Laney | should be using that then (i.e. ghc gets the blame) | 15:51 |
| BenC | Laney: is there a way to build ghc that would be more "safe" rather than fast or native? | 15:51 |
| Laney | I think the right solution is to be using llvm | 15:51 |
| seb128 | barry, doko: CFLAGS="-g -O0-Wall" python-config --cflags ... returns an attributeerror 'NoneType' object has no attribute 'split' on precise | 15:52 |
| cjwatson | jibel: (I'm downloading and restoring the apt-clone state here and want to know how to reproduce the problem locally - even if somebody else is already on top of this one, I want to develop this skill anyway) | 15:52 |
| seb128 | barry, doko: is that a known python bug? | 15:52 |
| seb128 | using python2.6-config works | 15:52 |
| BenC | Laney: How do I force that? (I don't mind rebuilding ghc) | 15:52 |
| seb128 | that breaks the build of some GNOME sources | 15:52 |
| doko | seb128, yes, need to fix that | 15:53 |
| seb128 | doko, do you have any workaround or eta for the fix? | 15:53 |
| slangasek | jibel: I guess when you get right down to it, I don't understand what your comment says, or how that would interfere with the eatmydata benefits... are you doing the upgrades entirely in a ramdisk? | 15:53 |
| jibel | slangasek, yes with eatmydata. | 15:53 |
| Laney | BenC: not sure I'm afraid, but you should be able to pass -fllvm at compilation time | 15:53 |
| seb128 | doko, it's blocking some updates I'm working on | 15:53 |
| Laney | BenC: I'm looking at http://www.haskell.org/ghc/dist/current/docs/html/users_guide/code-generators.html | 15:53 |
| Laney | maybe there are gremlins I'm not aware of though | 15:53 |
| jibel | cjwatson, the configuration of the job is not published on the public instance. | 15:55 |
| Laney | hrm, that is for a newer version than we have in Debian | 15:55 |
| cjwatson | jibel: is it in a bzr branch somewhere, say? | 15:55 |
| doko | seb128, don't set CFLAGS explicitly. it should do the correct thing. but call python-dbg-config for the -debug build. | 15:55 |
| seb128 | doko, I don't set CFLAGS, something in the toolchain do it for me | 15:55 |
| BenC | Laney: ghc: panic! (the 'impossible' happened) | 15:55 |
| BenC | Laney: not much better :) | 15:55 |
| Laney | heh | 15:56 |
| seb128 | doko, toolchain -> packaging tools | 15:56 |
| Laney | try with 7.4 in exp | 15:56 |
| Laney | this is where I defer to debian-haskell :P | 15:56 |
| seb128 | doko, "dpkg-buildpackage: export CFLAGS from dpkg-buildflags (origin: vendor): -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security | 15:56 |
| seb128 | " | 15:56 |
| seb128 | doko, not sure I can get around that (python-config is called by the configure) | 15:57 |
| cjwatson | but the CFLAGS you quote is completely different | 15:58 |
| BenC | Laney: ok, building that on precise now. Thanks for your help | 15:59 |
| seb128 | cjwatson, right, I took a random example, CFLAGS= python-config --cflags will break | 15:59 |
| Laney | np | 15:59 |
| seb128 | cjwatson, i.e any python-config --cflags call will fail if CFLAGS is defined it seems | 15:59 |
| cjwatson | you could 'unset CFLAGS; ./configure' as a temp workaround, presumably | 16:00 |
| cjwatson | (or env -u CFLAGS ./configure, neater) | 16:00 |
| cjwatson | obviously that means you lose hardening flags so it's not great | 16:00 |
| seb128 | right | 16:00 |
| seb128 | which is why I was reluctant to do it | 16:01 |
| seb128 | I might just replace the python-config call by its result as a workaround until python is fixed | 16:01 |
| seb128 | i.e hardcode the result | 16:01 |
| seb128 | cjwatson, doko: thanks | 16:01 |
| doko | well, hardening flags are turned on by default, so you only loose the -Wformat-security | 16:02 |
| doko | I'll have to fix that | 16:02 |
| jibel | cjwatson, https://wiki.ubuntu.com/QATeam/UpgradeTestingSetup | 16:02 |
| === JanC_ is now known as JanC | ||
| BenC | Laney: _s235 = _s1Xh >> 0x20U; | 16:03 |
| BenC | Laney: this is where the problem is coming in to play…it's trying to do a bit shift of 32 on a 32 bit value…maybe it works on other architectures, but not powerpc :) | 16:04 |
| jibel | cjwatson, checkout update-manager from bzr then go to update-manager/AutoUpgradeTester and run ./auto-upgrade-tester profile/lts-main-all | 16:04 |
| BenC | I suspect that affectively nulls the value, but I'm not sure why you would do it like that | 16:04 |
| cjwatson | jibel: ah, great, thanks | 16:05 |
| jibel | cjwatson, from an apt-clone run auto-upgrade-tester <clone_file> | 16:05 |
| jibel | cjwatson, it will create a base image from the clone and upgrade it | 16:05 |
| BenC | Or it's expecting a 64-bit var but using a 32-bit by mistake | 16:06 |
| cjwatson | looks like 'do-release-upgrade -d -f DistUpgradeViewNonInteractive' should be a decent start given an existing chroot | 16:07 |
| cjwatson | (my chroots are slightly hacked) | 16:07 |
| jibel | slangasek, the tests are running on qcow2 images on physical disks. I also tried with raw instead of qcow2 and cache=unsafe but the difference with the defaults settings is very small (10s or so for a 4 minutes upgrade) | 16:12 |
| jibel | slangasek, FYI the server I used uses hw raid | 16:13 |
| slangasek | jibel: hmm, but the point of eatmydata is that the kernel doesn't have to flush it out to the underlying disk at all | 16:14 |
| slangasek | I would expect this to have the same effect whether the disk is a virtual image or not | 16:14 |
| slangasek | but anyway, if the whole upgrade only takes 4 minutes, yeah, it's not worth it | 16:14 |
| jibel | slangasek, that was what I expected too and was surprised by the result. I'll try on a smaller system and bigger upgrades. | 16:16 |
| slangasek | jibel: what filesystem are you using within the VM? | 16:17 |
| jibel | slangasek, ext4 | 16:17 |
| mvo | slangasek: sorry, had a call - just the version in each release is my gut feeling | 16:30 |
| === dendrobates is now known as dendro-afk | ||
| slangasek | jibel: right, nothing unusual there... I dunno then | 16:44 |
| slangasek | mvo: ok | 16:44 |
| === arand_ is now known as arand | ||
| === scott-work is now known as scott-work-afk | ||
| === scott-work-afk is now known as scott-work | ||
| BenC | Laney: Same errors with experimental ghc 7.4 | 17:27 |
| * BenC drops this, wasting too much time on it | 17:27 | |
| Laney | BenC: OK, good findings anyway. If you could mail your summary to d-haskell someone will probably send it upstream | 17:33 |
| BenC | Laney: | 17:33 |
| BenC | Laney: ok | 17:33 |
| Laney | cool | 17:34 |
| Laney | why are you interested in this, OOI? | 17:34 |
| BenC | Trying to resolve ftbfs on powerpc | 17:34 |
| Laney | ah, no special haskell interest then | 17:35 |
| Laney | fair 'nuff | 17:35 |
| BenC | None whatsoever :) | 17:35 |
| YokoZar | Can someone tell me why opencl-headers is in multiverse? I want to build wine with it but this requires demotion of wine or promotion of opencl-headers | 17:39 |
| === yofel_ is now known as yofel | ||
| micahg | it's in contrib in Debian. that's probably how it ended up there | 17:41 |
| micahg | YokoZar: seems like a good candidate for universe, I'd suggest filing a bug and subscribing ubuntu-archive and then pinging someone if you need it sooner | 17:43 |
| * ScottK agrees | 17:44 | |
| * SpamapS jumps out of his chair when he realizes the speakers on his MBA are working in Linux now.. and the volume is all the way up. | 17:50 | |
| BenC | cjwatson: what's the usual process for something like powerpc packages failing in dpkg-gensymbols during build? | 17:57 |
| BenC | cjwatson: is it just a matter of getting the symbols updated for that arch? | 17:57 |
| om26er_ | hey mterry | 18:00 |
| om26er_ | can you please sponsor https://code.launchpad.net/~om26er/ubuntu/oneiric/nux/sru-819721/+merge/88592 | 18:00 |
| janimo | BenC, in the few cases I ran into similar with armel I just updated the symbols.armel package as the error suggested | 18:00 |
| BenC | janimo: and then reupload with that? | 18:01 |
| janimo | unless it is an error and some symbols should not be there but that needs knowledge of said package | 18:01 |
| janimo | BenC, yes, it only affects the specific arch | 18:01 |
| BenC | Ok | 18:01 |
| BenC | I suspect it's just a matter of the maintainer not having access to those symbols | 18:01 |
| BenC | janimo: thanks | 18:01 |
| janimo | BenC, np | 18:01 |
| cjwatson | BenC: yeah, generally what janimo said | 18:08 |
| * cjwatson bangs head against python3-apt | 18:08 | |
| dobey | hrmm | 18:15 |
| dobey | what's the best way to do "Depends: libgudev-dev | (libhal-dev >= 0.5 & libhal-dev < 0.6)? | 18:16 |
| BenC | dobey: I believe it's "don't do that"…but one way might be to have a virtual package that depends on the second half, and use that instead | 18:18 |
| cjwatson | or expand it using boolean idedntities | 18:18 |
| cjwatson | *identities | 18:18 |
| dobey | or i guess i can just not do it, since there doesn't seem to exist a hal 0.6 anyway | 18:19 |
| cjwatson | Depends: libgudev-dev | libhal-dev (>= 0.5), libgudev-dev | libhal-dev (<< 0.6) | 18:19 |
| YokoZar | ScottK: Bug filed, and thanks :) https://bugs.launchpad.net/ubuntu/+source/khronos-opencl-headers/+bug/918837 (Wine is currently in dep-wait on this, so at your convenience please) | 18:19 |
| dobey | ah right | 18:19 |
| cjwatson | but yeah, not having to do it is better :) | 18:19 |
| ubottu | Ubuntu bug 918837 in khronos-opencl-headers (Ubuntu) "Please promote opencl-headers to universe" [Undecided,New] | 18:19 |
| dobey | thanks cjwatson | 18:19 |
| ScottK | YokoZar: I don't have sufficient access for that I don't think. | 18:20 |
| YokoZar | I'm genuinely surprised to hear that there's something ScottK can't do :) | 18:21 |
| ScottK | YokoZar: https://launchpad.net/~not-canonical | 18:22 |
| YokoZar | ScottK: Joining that team now :) | 18:22 |
| mterry | om26er_, sorry, was afk. looking | 18:25 |
| om26er_ | ah no problem ;) | 18:25 |
| cjwatson | YokoZar: done | 18:27 |
| YokoZar | cjwatson: Thank you kindly! | 18:27 |
| cjwatson | ScottK doesn't have access because I haven't written the relevant Launchpad API patch yet, rather than as a matter of policy ... | 18:27 |
| ScottK | Right. If I worked for Canonical I could do it without said patch. | 18:28 |
| scott-work | cjwatson: apologies for bothering you again, do you require anything else from the ubuntu studio team WRT the live dvd? | 18:29 |
| scott-work | cjwatson: also, do we need to create the live or live-dvd seeds or is that something you need to do? | 18:29 |
| scott-work | cjwatson: and is there any further action we need to do independently? | 18:29 |
| cjwatson | scott-work: nope, I don't think so, I plan to sort it out this week | 18:31 |
| * cjwatson has been fixing upgrade bugs and fighting with python3-apt all today | 18:31 | |
| ScottK | barry: Is numpy on your python3 list? | 18:34 |
| barry | ScottK: not right now | 18:35 |
| ScottK | OK. | 18:35 |
| * scott-work was on phone with wife | 18:36 | |
| scott-work | cjwatson: outstanding! thank you ever so much for your help and assistance, and most importantly thank you for being patient and explaing things to me | 18:36 |
| scott-work | i greatly desire to learn :) | 18:36 |
| BenC | when things build-dep on binutils and bash-completions, I often wonder about the sanity of the maintainer | 18:43 |
| om26er_ | mterry, there there :) | 18:50 |
| mterry | om26er_, ? | 18:50 |
| om26er_ | mterry, did you look at my branch? | 18:50 |
| mterry | om26er_, yeah | 18:50 |
| mterry | om26er_, getting my virtual machine up so i can test it :) | 18:51 |
| om26er_ | mterry, awesome :) | 18:51 |
| om26er_ | the patch is from stable trunk fyi | 18:51 |
| lamont | ScottK: done. | 19:32 |
| lamont | ScottK: though if you want to do the sync-dance later, that'd be wonderful | 19:32 |
| ScottK | Will do. | 19:32 |
| smoser | SpamapS, slangasek any thoughts on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/898373 | 19:50 |
| ubottu | Ubuntu bug 898373 in cloud-init (Ubuntu) "fsck.ext3: Device or resource busy while trying to open /dev/xvda2" [High,Confirmed] | 19:50 |
| SpamapS | smoser: can you explain what the cloud-config stanza is trying to accomplish? | 19:53 |
| smoser | its not important | 19:54 |
| smoser | reproduced outside of that. | 19:54 |
| === dendro-afk is now known as dendrobates | ||
| slangasek | smoser: what's this about 'mount -a'? is this setup not using mountall? | 19:58 |
| smoser | also red-herring. | 19:58 |
| smoser | 'mount -a' only happens on first boot, when cloud-init sets up some mounts that are not in the image initially. | 19:59 |
| smoser | then, it issues 'mount -a' | 19:59 |
| slangasek | ah | 19:59 |
| smoser | to get them read. | 19:59 |
| smoser | but this occurred on subsequent boots. in this case, the 37th | 19:59 |
| smoser | comments 3, 4 and 5 are probably most relevant. | 19:59 |
| === deryck is now known as deryck[lunch] | ||
| slangasek | I don't know of anything else in the system that should cause the device to be busy | 20:01 |
| smoser | i guess 2 things that would have been useful here a.) i dont know if /mnt was mounted on the boot where there were errors. and b.) the subsequent reboot did not complain and now (some reboots later) /mnt is mounted fine. | 20:01 |
| smoser | what would 'mountall: Event failed' come from | 20:02 |
| slangasek | well, mountall can be run with --verbose to get more information | 20:04 |
| slangasek | not sure about the 'Event failed'; mountall itself doesn't seem to contain that error string | 20:05 |
| stgraber | slangasek: this is typically caused by one of the mounted-* failling. Last I saw it, that was mounted-dev failling on LXC getting some permissioned denied when calling MAKEDEV (fixed by my mountall change) | 20:13 |
| stgraber | (the string comes from upstart itself) | 20:14 |
| === salem_ is now known as _salem | ||
| mterry | @pilot out | 20:21 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| hallyn | lamont: hi, was wondering whether bug 913952 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655310) is on your radar? | 20:43 |
| ubottu | Debian bug 655310 in util-linux "getty fails when consoles are on devpts" [Normal,Open] | 20:43 |
| ubottu | Launchpad bug 913952 in util-linux (Ubuntu) "no console on precise containers" [Undecided,New] https://launchpad.net/bugs/913952 | 20:43 |
| lamont | hallyn: util-linux is on my radar for the plane this weekend | 20:45 |
| hallyn | lamont: great, thanks. | 20:45 |
| hallyn | actually, it appears now to be working. what on earth...? | 20:48 |
| kees | magic! | 20:49 |
| hallyn | any workaround sufficiently advanced... | 20:49 |
| kees | hehe | 20:49 |
| stgraber | hallyn: yeah, noticed the same thing. I guess the change in console.conf was enough to make getty work, though I suspect you'll still get some complaints in /var/log/boot.log and /var/log/upstart/* (if starting using -- /sbin/init --log) | 20:50 |
| hallyn | stgraber: that fix wasn't enough by itself before... for me anyway... huh. | 20:51 |
| hallyn | well i recon i better mark those invalid | 20:51 |
| hallyn | I'd wait, but i suppose i can always re-mark them valid if i need to | 20:52 |
| === deryck[lunch] is now known as deryck | ||
| hallyn | anyway i still have my slew of fixes on the other laptop from plane trip. hopefully i can get those uploaded by end of tomorrow | 21:10 |
| hallyn | jdstrand: stupid question. shouldn't "make test" automatically get run by debian/rules build? (re netcf) | 21:16 |
| jdstrand | hallyn: well, I thought so, but the build log said it was disabled for some reason | 21:17 |
| jdstrand | DEB_MAKE_CHECK_TARGET unset, not running checks | 21:17 |
| jdstrand | hallyn: ^ | 21:17 |
| hallyn | ok, thanks. will look more | 21:18 |
| jdstrand | hallyn: maybe you just need to set that in debian/rules. I'm not totally up on all the new dh stuff | 21:18 |
| jdstrand | hallyn: DEB_MAKE_CHECK_TARGET := check ? | 21:19 |
| * jdstrand stops looking | 21:19 | |
| hallyn | yup, thx - will try | 21:20 |
| hallyn | (got some kernels to crash first) | 21:20 |
| stokachu | hi any patch pilots in the queue? | 21:36 |
| seb128 | stokachu, https://www.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok@group.calendar.google.com | 21:36 |
| stokachu | ah sweet | 21:37 |
| seb128 | stokachu, none active in the topic but I guess you can wait tomorrow ;-) | 21:37 |
| stokachu | seb128, that sounds great :) thanks again i've got this bookmarked | 21:37 |
| seb128 | yw | 21:37 |
| seb128 | you can also watch the topic on this channel | 21:37 |
| seb128 | usually pilots put themself there during their shift | 21:38 |
| stokachu | ok cool, ill keep checking back .. maybe someone will show up later tonight | 21:38 |
| seb128 | stokachu, if you subscribe ubuntu-sponsors your bug,merge request will show up on http://reports.qa.ubuntu.com/reports/sponsoring/ | 21:39 |
| seb128 | stokachu, so you don't especially need to be pro active on IRC and ping | 21:39 |
| seb128 | it might just get sponsored by the normal reviews | 21:39 |
| stokachu | seb128, ok, cool just didn't want to get smacked for doing it wrong :D | 21:39 |
| seb128 | don't worry, people are usually nice here ;-) | 21:40 |
| stokachu | lol sounds good | 21:40 |
| seb128 | you might want to wait a few days if there is no hurry, usually no need of direct ping if things just landed in the queue | 21:40 |
| stokachu | ok that sounds good, yea this is no rush ive got other bugs to attend to :) | 21:40 |
| === bladernr_ is now known as bladernr_afk | ||
| hallyn | mdeslaur: haven't look into it at all, but - is it expected that nonfree flash plugin have sound in precise now? | 21:50 |
| mdeslaur | hallyn: you don't have sound? | 21:51 |
| hallyn | nope | 21:51 |
| mdeslaur | hallyn: file /usr/lib/flashplugin-installer/libflashplayer.so | 21:52 |
| mdeslaur | is it amd64 or i386, and are you running amd64 or i386? | 21:52 |
| hallyn | x86-64 | 21:52 |
| hallyn | (both) | 21:53 |
| mdeslaur | hallyn: do you have libasound2 installed? | 21:54 |
| mdeslaur | darn, gotta run, bbl | 21:54 |
| hallyn | yup, 1.0.24.1-4ubuntu1 | 21:55 |
| hallyn | ok - thx | 21:55 |
| mdeslaur | hrm, not quite sure what it could be for now...If I think of something, I'll let you know | 21:55 |
| hallyn | thx, ttyl | 21:56 |
| TheMuso | hallyn: Do you have libasound2:i386 installed? | 21:59 |
| hallyn | TheMuso: I do | 22:00 |
| TheMuso | hallyn: Do you have libasound2-plugins:i386 installed? | 22:25 |
| hallyn | TheMuso: yes | 22:25 |
| TheMuso | Hrm ok then, not sure what is going on. | 22:25 |
| hallyn | TheMuso: thx anyway - i'll look deeper into whether i have some apparmor thing going on. I wanted to amke sure whether it was workgin for others | 22:26 |
| cjwatson | lamont: you know you can sync your packages yourself nowadays, right? | 22:32 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| lamont | cjwatson: yeah. I'm aware that such technology exists. OTOH, I'm happy to let NEW take its time, and let ScottK enable me to not actually figure out the infrequent-for-me process.... | 22:45 |
| hallyn | well I assume this has something to do with it: | 23:07 |
| hallyn | Jan 19 17:05:37 sergelap pulseaudio[5690]: [autospawn] core-util.c: Failed to create random directory /tmp/pulse-guQWh6ykzqbl: Permission denied | 23:08 |
| TheMuso | hallyn: Interesting indeed. | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!