[00:31] is there any way to have apport still save a core file in to your pwd? [00:40] ogra_: I see that armhf doesn't have any of the arm-specific X video drivers; is this intentional? [00:46] RAOF: Example? [00:46] RAOF: And if it's just a case of someone doing s/armel/armel armhf/ in debian/control, feel free. [00:47] infinity: omapfb, tegra, msm. [00:47] RAOF: (And no, it's not currently intentional for anything on armel to not be also on armhf) [00:48] RAOF: Oh, except tegra, which is a binary blob. [00:48] Right. [00:48] RAOF: But anything that's actually free software (which I assume omapfb is?) should be compiled on armhf, yes. [00:48] I suspected as such. [00:48] Ok. [00:49] Yeah, omapfb is. [01:12] Hm. Is there a grep-dctrl rune for selecting packages which Depend on xorg-video-abi-10 *and* are only built on armel? [01:36] I take it no one cares too much about omapfb? Does anyone care if it uses softfloat an armhf? [02:01] RAOF: Err, what? [02:01] RAOF: If it uses the softfp ABI, it won't work on armhf. [02:02] That's not obvious to me. Good to know! [02:02] Anyway, turns out that what we actually want to do is sync from debian. [02:02] What's the package name in question? [02:03] xf86-video-omapfb [02:03] 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] It... Does? [02:04] packages.qa disagrees... Maybe it's lagging. [02:04] http://anonscm.debian.org/gitweb/?p=collab-maint/xf86-video-omapfb.git;a=blob;f=debian/control;h=66ec8b102e36c13a766f87bb2aca30bb44b86773;hb=012d94a229e639317a79fa3ad1eadc27d4f75b5a [02:05] Unless the tag lies, of course. [02:06] Oh, indeed. I was misreading something, based on the date. [02:13] Wow, that new device "detection" (and I use that term loosely) code is vile. [02:14] RAOF: But yes, syncing it looks like the right thing to do. [02:14] RAOF: (Pressing the button) [02:14] You don't need to. [02:15] Too late? :) [02:15] Heh. 'scool. It's staged in the Xserver 1.11 staging PPA with a -build1 version anyway :) [02:16] Oh. That seems silly. [02:16] But okay. [02:16] And I'm guessing -msm can just have debian/control mangled for great justice. [02:16] 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:17] Don't see why you wouldn't be able to copy from debian to a PPA. [02:17] Though I've never tried. [02:17] I don't know where the button is. [02:17] soren has a script for that I think [02:17] Well, it wouldn't require a script, per se. [02:17] Though, if you were scripting, you could sync-package --no-lp, and then upload to your PPA instead of the archive. [02:18] Which would actually make it look like a sync. [02:18] But. [02:18] Just copying the sources would be fine too. [02:18] Since no one gives a crap about what the .changes in a PPA look like. [02:18] a script could do it w/out transversing your machine though [02:18] micahg: I'm not convinced the web UI can't do it, though I haven't looked. [02:19] * infinity looks. [02:20] 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] syncpackage --no-lp will fiddle with Distribution in .changes. [02:20] ^ [02:20] It's the target in .changes that matters, not the one in the changelog. [02:21] syncpackage without --no-lp can't copy to PPAs yet [02:21] see Archive._checkCopyPackageFeatureFlags in LP [02:22] # We have no way of giving feedback about failed jobs yet, [02:22] # so this is disabled for now. [02:23] 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] RAOF: Multiarch sadness. [02:24] Hm. Execpt perhaps for the bit where it goes -march=armv7-a -mfpu=neon -mfloat-abi=softfp [02:24] 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] RAOF: That's also bad. :P [02:24] RAOF: Should be -mfloat-abi=hard (or not have the flag at all, since our compilers on armel and armhf get it right) [02:25] micahg: Which recent uploads? [02:25] Oh, indi-sbig? [02:25] 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:27] 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] It's not arch-specific because it "needs porting", it can't be ported. [02:28] micahg: Same deal for the other one, it would seem. [02:29] Aww, that's so cute. Hardcoding CFLAGS in Makefile.am [02:29] Speaking of porting, do I trust this fpc_armhf binary I just built? [02:29] 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] micahg: Sure, but if the dep changes, you're editing control anyway. [02:29] micahg: So, you can fix the arches. :P [02:29] micahg: Which is, actually, way less hassle than P-a-s. [02:30] argh [02:31] * cjwatson introduces gnome-games to Replaces [02:31] fpc uncleverly compiles everything statically, doesn't it? [02:31] Which means a new upstream version doesn't require a transition... [02:31] Hrm. [02:32] * 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:36] * RAOF decides that's enough arm faffing and goes to have some lunch. [02:54] 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] And this will fix tomorrow morning's CD builds, not to mention the ARM failures that are coming in now. [02:55] cjwatson: Can do. [02:55] Ta [02:55] I'm doing xubuntu-meta now since that doesn't need mahjongg to be in main [03:02] Argh, xubuntu-meta fell over with a Packages validation error [03:02] infinity: Would you mind doing xubuntu-meta as well? [03:03] 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] I can take care of xubuntu-meta [03:04] unless infinity wants to do it that is [03:11] woot, my touchpad works [03:11] stock precise seems to work perfectly on the MBA 4,1 .. yay [03:12] SpamapS: QUICK RELEASE [03:14] * 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:16] cjwatson: I can do both. [03:16] micahg: ^ [03:18] SpamapS: My beard's not that grey... :( [05:35] Good morning === bladernr_ is now known as bladernr_afk [07:12] 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:13] jibel: it has a header which explains the details; please let me know if you need it to do something different [07:37] pitti, good morning [07:37] jibel: bonjour Monsieur, ca va? [07:37] pitti, très bien et toi ? [07:38] jibel: je sui bien, merci! [07:38] jibel: working on user config migration test right now [07:38] pitti, thanks for the script, I'll add it to the upgrade test today. [07:38] jibel: trying to remember which other popular settings we mentioned, besides background image [07:39] jibel: for the system one it's sufficient to run it after upgrade [07:39] jibel: for the user one, we need a "prepare" shell script to run in the lucid environment; will that be possible? [07:40] pitti, yes it will. we can run a script right after the initial bootstrap to prepare the environment [07:40] 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:41] pitti, I added support to catch debconf prompts yesterday [07:41] 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] jibel: yay, with the fake editor trick? [07:42] jibel: ah, you both have a full log, and some "known good/bad" parts of it? [07:42] pitti, right. It was trickier than expected because the noninteractive frontend overrided the frontend. [07:43] pitti, I collect the full log then split it in pieces for each /unexpected/ prompt [07:43] jibel: ah, so you have to monkey-patch upgrade-manager for this? :) [07:43] pitti, there is also a whitelist for prompts we'd like to see anyway. [07:44] pitti, the node on which lts tests runs uses update-manager form bzr and I proposed a patch [07:44] *from [07:47] jibel: ah; I guess it's enough to not touch it if the environment already has it set? [07:48] pitti, yes, that's the patch. [07:50] jibel: do you remember anything else except background image and custom launchers? [07:50] good morning [07:51] jibel: oh, screensaver settings [07:51] jibel: e. g. lock/nolock and the timeout [07:52] jibel: .. and I'll set the Radiance theme and check that this is maintained [08:00] didrocks: ISTR that unity migrates the old panel launchers, does it? I'd like to add it to my LTS upgrade test script [08:01] pitti: yeah, it migrates: icons in the panel launcher as well the ones on the desktop [08:01] it tries to merge them as well [08:01] (I think we don't want to test migrating from cairo-dock, awn, and other docks that it supports too) [08:02] 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:03] yeah, sounds right === smb` is now known as smb [08:12] 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] pitti, we could also check that proxy and a11y settings are preserved [08:15] 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] jibel: proprietary drivers is not on my todo list, right? [08:20] 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:26] 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* === Quintasan_ is now known as Quintasan [09:31] 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] 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:32] hmkay [09:32] 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] (on UNE) [09:33] didrocks: let me try it, and I'll add it to the test cases [09:33] 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] pitti: indeed :) [09:33] (changing that will take me 10s FYI in the migration script), so just need to take the time to talk to John [09:35] didrocks: oh, so it actually copies the .desktop file to someplace else then? [09:36] didrocks: for the panel launchers it just keeps the ones in .gnome2/panel/... [09:36] pitti: I need to refresh my memory, one moment [09:36] 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:38] pitti: yeah, was definitively at the time we used UNE and didn't show desktop [09:38] pitti: so, they are not copied, which seems indeed useless right now [09:39] pitti: I'll catch this up with John :) [09:39] didrocks: merci [09:39] pitti: thinking about that, we need to handle the transition from UNE 10.04 -> ubuntu 12.04 [09:39] pitti: it should import the favorites from netbook-launcher [09:39] didrocks: ah, indeed [09:39] pitti: de rien :) [09:39] sounds like a nice additional test case, too [09:40] indeed [09:45] didrocks: ah, it's clever enough to just say "gucharmap.desktop" [09:45] didrocks: instead of Desktop/gucharmap.desktop" [09:45] didrocks: so that part technically works, although it's looking strange [09:45] so I'll do add a totally custom launcher, too [09:45] pitti: yeah, I have a quite long algorithm to try to prefer system ones [09:46] matching on desktop name, then on exec key name… [09:46] morning: can someone help me with this package build failure [09:46] https://launchpadlibrarian.net/90422989/buildlog_ubuntu-precise-armel.hadoop_0.20.205.0-0ubuntu1~hadoop4_FAILEDTOBUILD.txt.gz [09:46] that's what I meant by "merging the launcher" [09:46] (and why you don't have two firefox.desktop launcher icons) [09:47] package build fine on the other four architectures and on some armel builds; dpkg-shlibdeps is doing something weird [09:47] builds just fine on my local armel install :-( [09:52] didrocks: ok, got all four covered now [09:52] excellent! thanks pitti :) [09:52] didrocks: avec plaisir! [10:27] hi [10:28] I think I managed to crash unity up to the point where it does not start even [10:28] how can I find out what's going on? [10:28] is there any log, can I run debug mode? [10:33] fijal: .xsession-errors? [10:34] where? [10:34] in . [10:34] ? [10:34] er [10:34] in ~ [10:34] in ~ [10:34] (unity-window-decorator:2146): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed [10:34] I'm kind of used to that CRITICAL [10:34] you'll see lots of thnigs like that [10:35] also, this isn't really a support channel, but if you want to get it back to a sane state: unity --reset [10:36] 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:37] tumbleweed: I know this is not a support channel, but I'm trading priority support for priority support I guess :) [10:55] jibel: I have the user settings part ready now as well, BP updated === _salem is now known as salem_ [11:54] pitti: can you please copy ubufox/lucid to lucid-proposed and ubufox/maverick to maverick-proposed from ubuntu-security-proposed? [12:13] tumbleweed: saw that, will do! === MacSlow is now known as MacSlow|lunch [12:47] micahg: oh, just ubufox, not firefox and the langpacks? [12:48] micahg: oh, nevermind, misread [12:48] micahg: sure [12:51] micahg: done [13:12] pitti: thanks [13:20] mvo: hmm, lovely :P [13:20] slangasek: the unstoppable david worked it out in the end [13:20] ok :) [13:21] preparing a version (again!) [13:24] mvo: is there a particular reason there's no DistUpgrade.cfg.precise in update-manager yet? [13:24] was just looking for how it handled the removal of the transitively-essential lzma, and couldn't find anything [13:25] oh, looks like update-manager doesn't have the same transitively-essential handling that apt itself does [13:25] so I guess it wouldn't run into that [13:27] @pilot in === 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 [14:15] hey barry - with http://blog.bazaar.canonical.com/?p=405 do we have to fix/change our docs? [14:16] ooh, those are exciting fixes [14:18] in ec2 instances, i get errors to the console on boot of 'mountall: Event failed' [14:19] that seems to generally be not a problem, but I'm wondering if anyone would know the source of that message. [14:19] 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:23] cyphermox: hey there [14:26] dholbach: we will :) [14:27] slangasek: hey [14:27] is this about bluez? [14:27] cyphermox: yeah ;) hold that thought, I'm just getting upgraded from -0ubuntu1 to -0ubuntu3 [14:28] (dunno why update-manager hadn't told me about it yet) [14:28] yeah, it was majorly messed up, sorry [14:30] cyphermox: so, after upgrading from -1 to -3, I see the following problems so far: [14:30] - bluetooth-daemon service is still running and can't be stopped (because the job file no longer exists) [14:30] - /etc/init/bluetooth-daemon.conf.dpkg-backup is left behind even though I never modified this file [14:31] hm [14:31] - package is considered successfully installed even though 'bluetooth' job hasn't been started [14:31] slangasek: the big issue was that -0ubuntu1 really, because if you upgrade straight from 4.96-* things work out properly [14:32] * cjwatson spies a pending libwmf merge that should take care of this messy upgrade bug [14:32] cyphermox: and the big issue: pulseaudio still doesn't see my headset [14:32] 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] (after manually shuffling jobs) [14:32] slangasek: rebooting would help [14:33] not acceptable ;) [14:33] slangasek: I know ;) initctl list | grep bluetooth ? [14:33] $ sudo initctl list | grep bluetooth [14:33] bluetooth start/running, process 27296 [14:33] bluetooth-device (hci0:12) start/running [14:33] ah? [14:33] also, why are we trying to start/stop bluetoothd on device add/remove *anyway*? [14:33] but was your headset ever paired? let me get mine and test it on this system I just upgraded [14:34] what do you mean, "ever paired"? it's been working for a solid year [14:34] this is a regression [14:35] if I restart pulseaudio, I can now see it listed in 'hardware', but not available in the input/output list [14:35] (under gnome-control-center sound) [14:35] and pulseaudio didn't get upgraded, only bluez [14:35] 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:36] barry, should I file a bug about it? [14:38] slangasek: ah, what profile is used for your headset? [14:38] slangasek: A2DP? [14:39] cyphermox: I use both a2dp and hsp/hfp profiles; it looks like the sink is only missing in the a2dp profile [14:39] slangasek: right, I see that too [14:39] cyphermox: ok. should I file a bug report? [14:40] please [14:40] \o/ notebook working again ... [14:40] that's indeed a regression from 4.96, though it's better than what state 4.97 was in :) [14:40] slangasek: any help with fixing up that upstart job mess would be welcome [14:41] slangasek: the whole point of the upstart jobs was to avoid having bluetoothd running when you don' t have bluetooth devices though [14:41] why is that worthwhile? [14:41] unused daemons are cheap [14:42] but why keep it running when it' s not necessary [14:47] it makes up for the ones in use that are expensive [14:47] dobey: meh [14:47] heh [14:47] and there's no need to run things that aren't needed [14:48] saves resources, and energy, to not have them running [14:48] however miniscule the change is. but 2 million people using 0.01W less is a lot across the board [14:49] no, it doesn't [14:50] properly-written daemons don't wake up when not needed [14:51] they still occupy N bytes of memory, which requires electricity [14:51] the memory is all powered regardless [14:51] this is a false optimization [14:51] 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] this was once parodied as "zeroes use less power than ones" [14:51] the only time it matters is if you have memory pressure on the machine [14:52] keeping the daemon running actually helps to avoid cycles the next time you need it again [14:52] but you probably have firefox running, so bluetoothd is lost in the noise :P [14:52] I do agree that bluezd should not start up until you actually have a bluetooth device (or the killswitch on) [14:54] cjwatson: that was from the pre-CMOS time? [14:54] (when it probably was quite true) [14:54] well running process might not use cpu but they use memory [14:55] not to mention they take time to start so slow boot [14:55] pitti: nope, Ubuntu era [14:55] on-demand starting of bluetoothd seems fine, sure [14:55] but the stopping is really unnecessary [14:55] seb128: right, speaking of automatic shutdown [14:55] (and probably racy, for that matter) [14:56] 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] cjwatson: reminds me of "investigate power difference between black or white screen (even for DPMS off)" [14:56] pitti: that one was investigated and did show power savings ;) [14:56] stgraber: yes, cyphermox was looking into making the enable/disable persistent across reboots [14:56] slangasek: right [14:57] slangasek, right, but it was the white screen (surprisingly!) that was most power efficient? [14:57] 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] diwic: on an LCD, yes. [14:57] slangasek: but I wonder when someone actually measured power consuption with all (free) memory set to 0 or 1 :) [14:57] stgraber: the soft kill switch needs to be persistent *regardless*, and stopping the daemon doesn't help with that at all [14:57] seb128: pitti: not simple, unfortunately, since upstream decided gnome-bluetooth was not the right place to do this. [14:57] but not surprising at all [14:57] dobey: it is surprising as it said "even with dpms off", i. e with the screen being powered down [14:59] cyphermox: *nod*; but at least I think we all agree that it's generally a good idea [14:59] pitti: dpms on an LCD doesn't exactly power the screen down though [15:00] at least not in the same way it does on a crt [15:00] 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] i want an oled screen, but nobody makes any with a good resolution :( [15:01] slangasek, cyphermox: Sounds like we just need to dump /sys/class/rfkill/*/soft and restore at boot time [15:01] that would be nice [15:01] stgraber: yeah, sure [15:01] I mean, everybody would probably be quite happy about it :) [15:01] (probably checking it's the same device too :)) [15:01] k, will do it later today then, should be pretty easy to do with a simple upstart job [15:03] 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:04] yep [15:10] http://paste.ubuntu.com/809717/ - anyone object to the creative solution of sticking a no-op prerm in the new libwmf0.2-7? [15:12] isn't that the standard workaround? :) [15:12] I hadn't encountered it before [15:13] ah... I have [15:13] anyway, no objection :) [15:15] where, out of curiosity? [15:15] hmm, been a while since I've run into it actually [15:15] so probably nowhere readily discoverable [15:16] * cjwatson notices that policy does actually have some careful wording about this nowadays [15:16] 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:17] 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:18] doko: Any ideas on the ghc assembler errors on powerpc that is causing, for example, haskell-hashtables to fail to build? [15:19] https://launchpadlibrarian.net/87619504/buildlog_ubuntu-precise-powerpc.haskell-hashtables_1.0.0.0-1build1_FAILEDTOBUILD.txt.gz [15:22] BenC, sorry, no. did it build before, or in Debian? [15:22] * doko reboots [15:22] doko: no idea, just getting into it [15:23] doko: doesn't exist on ubuntu-ppc [15:23] hrrm…guess I assumed doko was using screen [15:31] slangasek, cyphermox: http://paste.ubuntu.com/809739/ (rfkill-store.conf) and http://paste.ubuntu.com/809740/ (rfkill-restore.conf) [15:32] stgraber: is the name guaranteed to be whitespace-clean? [15:35] doko: it doesn't appear to have ever built on ubuntu at least [15:35] ubuntu-powerpc that is [15:35] BenC, good =) [15:35] Laney, ^^^ [15:35] * Laney perks up [15:36] ah, yeah, I meant to raise that. It fails the same way on Debian. [15:36] 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] stgraber: ok - looks fine to me then [15:36] if you're brave you can pass -keep-s-files to see what's going on [15:36] stgraber: which package will own this? rfkill itself? [15:36] Laney: I did that [15:36] and another interesting thing would be to try building with ghc from experimental [15:37] 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] Laney: srwi 3, 4, 32 [15:37] slangasek: yeah, I'd make it part of rfkill even though it doesn't depend on the rfkill tool itself [15:37] Laney: that's the 32 that it claims is out of range [15:37] failing that I believe Erik de Castro Lopo in pkg-haskell is interested in ppc issues [15:37] slangasek: oh, correct indeed. I based it on alsa-store but [016] is indeed better [15:37] d-haskell@ is a good venue [15:37] Ok, thanks [15:38] stgraber: cool - thanks for taking care of this [15:38] 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:39] BenC: powerpc is a community supported arch as far as GHC upstream are concerned, with all that that implies [15:39] stgraber: on plane you should be using the hardware switch! :) [15:41] slangasek: indeed :) [15:41] mvo: do you remember what this workitem for lts-upgrades means?: "grep maintainer scripts for dpkg --compare-versions" [15:42] 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] Laney: I'm not familiar with ghc…does it actually emit the assembler or go through gcc somehow? === dendrobates is now known as dendro-afk [15:42] IOW, where does the blame lie? [15:42] mvo: so which maintainer scripts are supposed to be grepped? [15:43] 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] slangasek: ideally all I would assume [15:43] slangasek: but thats obviously a bit of work [15:44] 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:45] 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:46] slangasek: this is what I remember from the discussion, yes [15:46] (from the UDS discussion) [15:46] mvo: ok - let me expand that description so it's clearer then, thanks [15:46] 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? === dendro-afk is now known as dendrobates [15:49] 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] 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] we should investigate using the LLVM backend more [15:50] jibel: what doesn't improve performance? eatmydata? [15:50] Laney: ,("Unregisterised","NO") [15:50] BenC: "Have native code generator"? [15:50] Laney: Yes for native and llvm [15:51] 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] should be using that then (i.e. ghc gets the blame) [15:51] Laney: is there a way to build ghc that would be more "safe" rather than fast or native? [15:51] I think the right solution is to be using llvm [15:52] barry, doko: CFLAGS="-g -O0-Wall" python-config --cflags ... returns an attributeerror 'NoneType' object has no attribute 'split' on precise [15:52] 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] barry, doko: is that a known python bug? [15:52] using python2.6-config works [15:52] Laney: How do I force that? (I don't mind rebuilding ghc) [15:52] that breaks the build of some GNOME sources [15:53] seb128, yes, need to fix that [15:53] doko, do you have any workaround or eta for the fix? [15:53] 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] slangasek, yes with eatmydata. [15:53] BenC: not sure I'm afraid, but you should be able to pass -fllvm at compilation time [15:53] doko, it's blocking some updates I'm working on [15:53] BenC: I'm looking at http://www.haskell.org/ghc/dist/current/docs/html/users_guide/code-generators.html [15:53] maybe there are gremlins I'm not aware of though [15:55] cjwatson, the configuration of the job is not published on the public instance. [15:55] hrm, that is for a newer version than we have in Debian [15:55] jibel: is it in a bzr branch somewhere, say? [15:55] seb128, don't set CFLAGS explicitly. it should do the correct thing. but call python-dbg-config for the -debug build. [15:55] doko, I don't set CFLAGS, something in the toolchain do it for me [15:55] Laney: ghc: panic! (the 'impossible' happened) [15:55] Laney: not much better :) [15:56] heh [15:56]