[00:06] <boax> the bug is:  glamor shouldn't be passing in a NULL destination to fbCopy.
[00:06] <boax> big thanks to RAOF
[00:09] <jtaylor> doko: why did you patch julia to build on all arches?
[01:14] <Bluefoxicy> Hmm.  Well good.
[01:14] <Bluefoxicy> My video card works in Ubuntu 15.04, even though it's still terminally broken in 14.10
[01:51] <psusi> cyphermox, hey there.. just wanted to make sure you understood my comments on bug #1418706, re the changes you made to partman-auto only masking the problem instead of addressing the root cause... just here if you wanted to discuss it
[01:51] <ubottu> bug 1418706 in ubiquity (Ubuntu) "Vivid: UEFI: blank drive incorrectly detected as existing BIOS-mode install" [Critical,In progress] https://launchpad.net/bugs/1418706
[02:58] <cyphermox> psusi: I'm not denying there may be other issues with installing for EFI right now, but the fix I uploaded is technically correct -- there was a genuine bug in the way partman-auto created the ESP which confused partman-efi. if you manually partition and create no ESP, then that's still bad for an efi setup and ubiquity should prompt (but that prompt should work properly... if it does not, then that's another matter)
=== timchen1` is now known as timchen119
[03:14] <psusi> cyphermox, that's really only a tangentally related issue... partman-auto set the partition to ext2 in partman's view of what partitions to create... but that really doesn't matter... the point is that the init.d script is supposed to be run before the visual.d script from partman-auto ever tries to create any partitions
[03:14] <psusi> it's supposed to be looking at what partitions are on the disk *before* you tried to install ubuntu... i.e. do you already have a windows install bootign in bios mode
[03:15] <psusi> the partitions that ubuntu is about to create isn't what it is supposed to see, even if they do not quite accurately reflect the eventual intended use ( fat32 / esp )
[03:16] <cyphermox> psusi: I thought I had explained this on the bug; the scripts *are* being run in the correct order, but they are also being run more than once, which is a difference from d-i installs, that's why you'd see a message afterwards. that the message is appearing for the "intended" partition set isn't necessarily wrong in this case since it can alerts the user that they are about to do something wrong.
[03:17] <cyphermox> psusi: btw, what timezone are you in? I really should start getting to bed :P
[03:17] <psusi> that's the job of the check.d scripts, the init.d scripts are intended to be run only *before* any other scripts ( visual.d ) start making changes in memory
[03:18] <psusi> EST, us
[03:19] <psusi> in other words, the check.d scripts warn you that you failed to create an esp and one is needed since you appear to be booting in efi mode... the init.d script is trying to see what OSes you already have installed before any changes are made
[03:19] <cyphermox> partman-efi's check.d currently doesn't try to warn you about a missing EFI partition
[03:20] <psusi> I'm pretty sure they do... but they aren't currently working under ubiquity
[03:20] <cyphermox> regardless, could you file a bug about the very specific issue you're seeing? keeping in mind that currently, partman itself runs more than once, so of course you'll get one run of init.d, visual.d, check.d, and then again with init.d, visual.d, check.d as it goes to handle the partition requests
[03:21] <psusi> that is to say, that if under d-i, you do manual partitioning, and don't create an esp, the check.d script says hey, you should have done that, go back?
[03:21] <cyphermox> I don't know, I looked before and I don't recall seeing it
[03:22] <psusi> when I contacted the debian guys about this, they seemed to be clear thta the scripts are to run in the order of init.d -> visual.d -> check.d... if they are being run again that is an error
[03:22] <cyphermox> but that said, it was broken anyway, because init.d would write out /var/lib/partman/ignore_efi and thus break later scripts
[03:22] <cyphermox> and update.d/efi_sync_flags wouldn't fix things either.
[03:22] <cyphermox> so all in all, it feels like steps in the right direction
[03:22] <psusi> right... because init.d is supposed to run first, and only if you already have windows that is apparently booting in bios mode, it disables all of the later efi stuff so you don't get the warning about lacking an esp
[03:24] <psusi> ( since the presumption is that if windows is already installed in bios mode, this machine must be capable of bios boot, even though yuo booted the installer in efi mode )
[03:25] <cyphermox> that still works
[03:25] <cyphermox> you can always hit "go back", and you won't be in UEFI mode.
[03:25] <psusi> only if you hit it within 2-3 seconds... later than that and the dialog box hangs
[03:26] <cyphermox> AFAIK, besides running partman/parted_server twice, ubiquity currently does more or less the right thing
[03:26] <cyphermox> fair enough. that's fixable
[03:26] <psusi> from what the debian guys told me, "the right thing" is to run init.d, then visual.d, then check.d... and NOT go back and run init.d again
[03:27] <cyphermox> I know it would be best, but things are the way they are
[03:27] <psusi> since they are all written with the assumption that they are run first
[03:27] <cyphermox> and things do currently mostly work
[03:27] <cyphermox> psusi: in other words, if you already have ideas on how to improve the situation and time to work on it, feel free to start on ubiquity's ubi-partman.py
[03:28] <cyphermox> I don't expect I'll be able to get to anything like that until next week, for sure ;)
[03:29] <psusi> well, I guess what I'm trying to say is that ubiquity running the scripts a second time is fundamentally broken but I currently lack the time and python/ubiquity knowlege to fix it ;)
[03:29] <cyphermox> as far as Debian things go, the patches I made to partman-auto still need to make it, because they *do* confuse partman-efi to some degree; bits go missing
[03:29] <cyphermox> psusi: what I'm saying is it might be broken or suboptimal, but it mostly works, minus some warts like that particular prompt
[03:30] <psusi> I suppose that does at least avoid the message in the most common case
[03:30] <cyphermox> making us wait for the prompting to be done / partitioning to be mostly complete can be fixed fairly easily I think
[03:30] <psusi> but the other really large wart involved here is the fact that when you do get the message, ubiquity seems to hang the window and continue without waiting for the response
[03:30] <cyphermox> yes
[03:30] <cyphermox> ^^
[03:31] <cyphermox> that's because ubiquity currently happily runs through questioning the user for what it needs and doing other work in the background
[03:32] <psusi> another long standing and likely related bug is that the check.d scripts are supposed to stop you and tell you that you forgot to create a bios_grub partition when you are in a bios booting but gpt partitioned machine and they don't... so later grub install fails and we get crash reports
[03:32] <cyphermox> so; provided the check scripts run properly, I'm guessing you wouldn't see the dialog anymore either, because it's failure cases would prevent the later run of init.d scripts to trigger thinking things are booted in EFI without an ESP
[03:32] <cyphermox> psusi: wouldn't that explode on d-i too currently?
[03:33] <cyphermox> there's only one check.d script for partman-efi, it's doing the too_small_efi and no_efi tests only
[03:35] <psusi> from what I can tell, the architecture of partman is for init.d to run first, then visual.d, possibly several times, then check.d, possilbly going back to visual.d, then finally commit.d exactly once
[03:35] <cyphermox> psusi: if you file the bugs for these issues, I'll eventually get to them
[03:35]  * cyphermox shrugs
[03:36] <psusi> ok... so I should file a separate bug?  and you consider that one closed?  I wasn't sure since it didn't get closed because you didn't reassign it to partman-auto before uploading that
[03:37] <cyphermox> psusi: I think we can consider that one closed, as the most common cases don't cause the install to be unusable
[03:37] <cyphermox> let me fix that
[03:43] <cyphermox> and it's late, so I'll get some sleep before it's tomorrow. :)
[05:18] <infinity> slangasek: Did you get around to having opinions about the PAM/FD_SETSIZE thing?
[07:11] <dholbach> good morning
[07:17] <pitti> rbasak: patch looks good to me; you could perhaps clarify the description that PAM reads the defaults from pid 1 (which is different between upstart and systemd)
[08:05] <rbasak> pitti: sure - I take it you mean the dep3 description?
[08:09] <infinity> rbasak: +1 on the patch from me too, if it's tested to DTRT.
[08:09] <infinity> rbasak: Guessing slangasek is too timezone skewed from us for a timely review, so I'm fine with us getting it in and then letting him complain later.
[08:10] <rbasak> infinity: thanks. I don't mind waiting, but maybe you actually want it uploaded sooner?
[08:11] <infinity> rbasak: Well, we can wait a bit, but we'd like to be spinning final ISOs by Uk evening.
[08:11] <rbasak> OK
[08:34] <Odd_Bloke> rbasak: infinity: If this is something that we're going to want in the cloud images (which, from my limited understanding of the issue, it is), then UK evening will be pushing getting the images sync'd out everywhere.
[08:34] <rbasak> Odd_Bloke, infinity: OK I'll fix up and upload now.
[08:35] <infinity> rbasak: Ta.
[08:35] <Odd_Bloke> rbasak: Much appreciated.
[08:35] <infinity> Odd_Bloke: Well, to be fair, we don't imply that the archive will be closed and "released" until Thursday, so one would hope you're prepared to respin cloud images for an emergency.
[08:36] <infinity> Odd_Bloke: But we'll aim for not having any emergencies. :P
[08:37] <Odd_Bloke> infinity: We're prepared, but can't do anything about the 12 hour+ replication time in Azure. :p
[08:38] <Odd_Bloke> So, yeah, let's aim to find problems _after_ release; it's much easier for me that way. ;)
[08:40] <infinity> Odd_Bloke: Heh.  For me too. :P
[09:54] <pitti> barry: do you still target bug 1377184 for 15.04?
[09:54] <ubottu> bug 1377184 in system-image (Ubuntu) "move archive_master file out of /etc to avoid it being treated as a conffile" [High,Triaged] https://launchpad.net/bugs/1377184
[09:54] <pitti> barry: if so, now is the time :)
[10:08] <infinity> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: Final Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
[10:24] <seb128> Mirv, hey, I think your bug about click env failing to build a schroot with ecryptfs is bug #1427264
[10:24] <ubottu> bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,Triaged] https://launchpad.net/bugs/1427264
[10:24] <seb128> tyhicks and hallyn_ were discussing it but I don't think anyone managed to get slots to work on it before vivid :-/
[10:25] <seb128> we should probably recommend app devs to not use ecryptfs
[10:33] <tjaalton> does pandaboard run armhf?
[10:36] <Mirv> seb128: ok, good to know that there's an earlier bug about it!
[10:36] <ogra_> tjaalton, sure ...
[10:37] <tjaalton> ogra_: ok good, still need to find the power adapter..
[10:37] <ogra_> not sure if there are still recent images though
[10:37] <ogra_> (thats a question for infinity )
[10:42] <infinity> ogra_: There are, though I'm not sure if anyone tests them.  My panda is probably still running precise.
[10:42] <ogra_> mine hasnt been powered since over a year
[10:43]  * ogra_ has a sabrelite with proper SATA disk for builds ... way faster ... 
[10:44] <tjaalton> I'd need trusty to test lts backports
[10:44] <tjaalton> perhaps makes more sense to just get Rpi2
[10:46] <tjaalton> meh, out of stock until 15th of may
[11:01] <flexiondotorg> infinity, I see you are piloting. We discussed this merge last week - https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116
[11:01] <flexiondotorg> infinity, Any chance that can be merged and uploaded?
[11:02] <infinity> flexiondotorg: Erk, I thought we got that in.  I'm not amzingly comfy with doing it right before what I hope will be the final images.
[11:03] <infinity> flexiondotorg: Because if it *does* break another gtk2 flavour in a way you didn't expect, we'll not notice in time, or we'll delay the release for that flavour.
[11:03] <flexiondotorg> infinity, You agreed to do it but I guess you got busy.
[11:03] <flexiondotorg> infinity, So defer this to 15.10?
[11:04] <infinity> flexiondotorg: Yeah.  I think it's better to do it post-release at this point (so, in 15.10, and as an SRU to 15.04), so it can have more testing.
[11:04] <flexiondotorg> infinity, I'm happy to just do this for 15.10.
[11:04] <flexiondotorg> No SRU required.
[11:04] <infinity> flexiondotorg: Or that, sure.
[11:26] <sveinse> I'm trying to debootrsap vivid from utopic (debootstrap --variant=minbase vivid), but it fails with "Invalid release signature (key id 40976EAF437D05B5)". Any ideas? debootstrapping jessie worked fine
=== MacSlow is now known as MacSlow|lunch
=== alvesadrian is now known as adrian
[11:44] <rbasak> sveinse: are you running Ubuntu or Debian?
[11:45] <rbasak> /usr/share/keyrings/ has ubuntu-archive-keyring.gpg which contains that key. I'm not sure what debootstrap uses though.
[11:46] <rbasak> sveinse: also you might want to check the release signature by hand to check that you don't have some kind of mirror sync issue.
[11:56] <sveinse> rbasak: I'm running ubuntu (utopic)
[11:59] <rbasak> sveinse: perhaps you've hit bug 972077 then? The workaround is to retry a bit later.
[11:59] <ubottu> bug 972077 in apt (Ubuntu) "apt repository disk format has race conditions" [Medium,Confirmed] https://launchpad.net/bugs/972077
=== _salem is now known as salem_
=== sveinse_ is now known as sveinse
[12:27] <pitti> Riddell: bug 1413521 seems relevant for the final release; are you still working on this?
[12:27] <ubottu> bug 1413521 in kde-workspace (Ubuntu Vivid) "desktop folderview needs to be added on first boot on oem installs" [High,Confirmed] https://launchpad.net/bugs/1413521
[12:30] <Riddell> pitti: I'm pretty resigned to oem not working properly in this release :(
[12:31] <Riddell> I tried looking into it last week but was blocked on something not installing oem-config at all
[12:31] <Riddell> now there's tidying up to do such as https://launchpad.net/bugs/1447144
[12:31] <ubottu> Launchpad bug 1447144 in ubiquity (Ubuntu) "oem-config forgets to update /etc/sddm.conf" [Undecided,New]
[12:36] <Riddell> pitti: hang on you're removing milestones, that's the way I get my list of important bugs for kubuntu
[12:36] <pitti> Riddell: I moved them to vivid-updates for things that can be fixed in SRUs and which are unrealistic to get fixed by "now"
[12:36] <Riddell> yeah vivid-updates is good
[12:37] <pitti> Riddell: but the above would be a case where vivid-updates doesn't make sense
[12:38] <Riddell> pitti: do we have a milestone for whimsy wallnut yet?
[12:38] <pitti> Riddell: I tried the current kubuntu daily and at least live session and installer seem to work; we are buildling new images now, I'll do a kubuntu test install to check the sddm bugs
[12:38] <pitti> Riddell: yes, I created 15.05 to 15.10 last week
[12:40] <Riddell> pitti: remind me again what the monthly milestones are for, I've never used them, are they just for teams that like to target fixes on a monthly basis?
[12:40] <pitti> Riddell: pretty much, yes
[12:41] <pitti> Riddell: for vivid series targetted bugs we also have a vivid-updates milestone
[12:57] <voldyman> robert_ancell: ping
=== MacSlow|lunch is now known as MacSlow
[13:12] <robert_ancell> voldyman, hello
[13:14] <voldyman> robert_ancell: thanks for all the help, did you get my last email?
[13:14]  * voldyman has been bothering robert too much
[13:15] <voldyman> (greeter)
[13:15] <robert_ancell> right :)
[13:15] <robert_ancell> I was wondering who you were for a second
[13:15]  * voldyman == stalker
[13:16] <robert_ancell> voldyman, yeah, so you need to work out why the closure is not being called because all sorts of X resources will get left behind otherwise
[13:16] <robert_ancell> The hoops you have to jump through to set an image on the root window and quit the greeter are a total pain in the ass
[13:16]  * robert_ancell loves X
[13:16] <voldyman> i tried using Posix to handle the term signal still didn't work
[13:17] <robert_ancell> voldyman, you need to use GLib or you'll get all sorts of race conditions
[13:17]  * robert_ancell loves Unix
[13:17] <voldyman> the weird thing is, lightdm's log shows that after sending the term signal greeter closed communication channel
[13:17] <voldyman> but greeter's logs don't indicate any signal was received
[13:17] <robert_ancell> voldyman, the channel is a socket so the process terminating will close it automatically
[13:17] <robert_ancell> I mean a pipe
[13:18] <voldyman> that is what is weird, no signal was received, the debug message after Gtk.main () wasn't logged hence the process wasn't killed
[13:19] <robert_ancell> voldyman, if the debug message wasn't there doesn't that imply the signal was received and it just didn't get handled?
[13:20] <voldyman> the debug call is in the code but is not logged hence i believe that, that part of the program wasn't reached or that lightdm closed the log file after sending sigterm
=== imcleod_ is now known as imcleod
=== doko_ is now known as doko
[13:23] <barry> pitti: re: si3.0 we can't land it until the server changes land
[13:23] <doko> ogasawara, apw: please be aware of https://gcc.gnu.org/ml/gcc/2015-04/msg00278.html
[13:23] <barry> pitti: so no, not 15.04 :/
[13:23] <ubottu> gcc bug 2015 in c++ "ICE in find_function_data, at function.c:330" [Normal,Resolved: fixed]
[13:24] <pitti> barry: ok, so moving milestone to 15.05 for now
[13:25] <pitti> barry: ah, you already moved to "later" (does anyone actually use that?)
[13:25] <robert_ancell> voldyman, if you handle SIGTERM and then do nothing in the handler is LightDM unable to kill the greeter?
[13:25] <barry> pitti: dunno!  15.05 would be okay too
[13:25] <robert_ancell> voldyman, that would confirm the handler is working
[13:25] <voldyman> ah, good idea
[13:40] <voldyman> robert_ancell: no effect, there was no signal handler before i added it after your email
[13:57] <doko> bdmurray, barry: what will we do with the requests issue?
[13:57] <voldyman> robert_ancell: i am totally lost, any more ideas? or any direction you would point me to?
[13:59] <barry> doko, bdmurray i'm not sure what to do.  i can't reproduce it
[14:00] <robert_ancell> voldyman, no idea. You need to confirm that you can handle SIGTERM and you are cleaning up on exit. Perhaps you need an explicit destruct method for the singleton.
[14:03] <voldyman> hmm, i'll check that.
[14:04] <voldyman> robert_ancell: Thanks a ton for all the help, i have bugged you a lot
[14:04] <robert_ancell> voldyman, np
[14:04] <robert_ancell> voldyman, I hope you get it working soon! It took us ages to get it to work for unity-greeter
[14:05] <voldyman> robert_ancell: i'll surely shoot you a an email when and if i am able to fix it
[14:32] <pitti> Riddell: I just did a kubuntu install with today's image, no problems with shutdown or sddm \o/
[14:32] <Riddell> pitti: awooga, thanks :)
[14:33] <Riddell> pitti: did you get bug 1436952 ?
[14:33] <ubottu> bug 1436952 in xorg (Ubuntu) "X crashes on some runs of Kubuntu live image returning in SDDM login" [Critical,Incomplete] https://launchpad.net/bugs/1436952
[14:33] <pitti> Riddell: do you still want to keep bug 1362599 open, or close it?
[14:33] <ubottu> bug 1362599 in Kubuntu PPA "ubiquity-dm does not transition to sddm to plasma5 desktop" [Undecided,Confirmed] https://launchpad.net/bugs/1362599
[14:33] <pitti> Riddell: no, all went well
[14:33] <pitti> Riddell: I only tested in QEMU so far, though; we can give it another shot on real hw
[14:34] <Riddell> pitti: bug 1362599 can be closed
[14:34] <Riddell> pitti: well I have several testers already, I expect you have other stuff needed tested :)
[14:34] <pitti> Riddell: ok, so much the better
[14:38] <pitti> Riddell: so we still have three 15.04 bugs about kubuntu/oem; so you're saying we don't care for this cycle? (most OEMs would only install LTSes anyway these days, I figure?)
[14:41] <bdmurray> doko: we can manually override a particular crash
[14:43] <Riddell> pitti: right, I'll just have to release note it
[14:44] <voldyman> robert_ancell: i think i might have found the problem
[14:45] <voldyman> i am using get_screen instead of Gdk.Screen.get_default and hence drawing on the windows root window not the X's root window
[14:45] <voldyman> http://bazaar.launchpad.net/~voldyman/pantheon-greeter/retain-back/view/head:/src/PantheonGreeter.vala#L301
[14:45] <voldyman> changed it but can't confirm the patch on Gnome-Boxes, waiting for another tester to confirm if this works
[14:47] <robert_ancell> voldyman, get_screen should return the same as Gdk.Screen.get_default as you tend to only have one "screen" on an X server.
[14:47] <voldyman> :/
[14:48] <voldyman> then another theory that i have is that, unity greeter has a main class that creates the window, pantheon greeter does everything from the window. that might be the reason why the window won't go away
[15:12] <slangasek> infinity, rbasak: I agree that capping the soft limit is correct behavior, GTM
[15:12] <slangasek> +L
[15:13] <infinity> slangasek: Excellent, cause that's what we did. ;)
[15:21] <voldyman> robert_ancell: i removed the RetainPermanent part and it worked enough for us, also found the reason for sig term, some function somewhere was calling Posix.exit :)
[15:41] <rbasak> slangasek: great. Thanks!
[15:52] <pitti> rbasak, slangasek: on a fresh server install my ulimit -n is 1024 again, FTR
[15:52] <rbasak> \o/ thanks
[15:55] <roaksoax-afk> pitti: https://pastebin.canonical.com/129999/
[15:55] <roaksoax-afk> pitti: any ideas?
=== roaksoax-afk is now known as roaksoax
[15:57] <pitti> roaksoax: oops, no
[15:57] <pitti> roaksoax: which arch/environment is that?
[15:58] <roaksoax> pitti: amd64 VM
[15:58] <roaksoax> pitti: apparently when installing isc-dhcpd-server works just fine, but when isntalling maas-dhcpd (from ppa:maas-maintainers/experimental) just fails
[16:01] <pitti> roaksoax: I tried with vivid's maas, and that fails with http://paste.ubuntu.com/10866717/ ; I'm trying the PPA now
[16:05] <pitti> roaksoax: can reproduce
[16:13] <roaksoax> pitti: any ideas as to why?
[16:13] <roaksoax> pitti: i'm fixing vivid maas now
[16:14] <pitti> roaksoax: no, haven't seen that yet
[16:14] <pitti> roaksoax: I uploaded the apport crash report, bug 1447243 now
[16:14] <ubottu> bug 1447243 in systemd (Ubuntu) "systemd crashes with Assertion 'current[*l + 1] == quotechars[0]' failed at ../src/shared/util.c:583," [Undecided,New] https://launchpad.net/bugs/1447243
[16:14] <roaksoax> pitti: thanks!
[16:14] <roaksoax> pitti: yeah, it completely crashes vivid in my case. I reboot after that failure and the machine never finishes coming up
[16:18] <pitti> roaksoax: yeah, it seems to mess up qemu, not even system_reset works
[16:18] <pitti> roaksoax: so, at first sight I'd say this assertion sounds like a quoting issue in one of the units
[16:18] <pitti> roaksoax: so, of course we'll fix systemd to not spill its guts that way, but I guess we also have a typo in some unit
[16:21] <roaksoax> pitti: ok, i'll investigate that, but then maas-dhcpd.postinst does this: systemctl stop isc-dhcp-server >/dev/null || true systemctl disable isc-dhcp-server >/dev/null || true
[16:21] <roaksoax> pitti: that should be ok right? or might that be causing the issue to happen?
[16:21] <pitti> roaksoax: that looks fine
[16:23] <roaksoax> pitti: this seems to be the unit with the source of the issue: http://paste.ubuntu.com/10866808/
[16:25] <pitti> roaksoax: apport just did its thing and we now have https://launchpadlibrarian.net/204019277/Stacktrace.txt
[16:25] <pitti> roaksoax: that indeed looks like it: filename = 0x7fe715ffddb0 "/lib/systemd/system/maas-dhcpd.service"
[16:27] <roaksoax> pitti: ok, I'll investigate
[16:27] <roaksoax> thanks
[16:27] <pitti> roaksoax: me too
[16:27] <pitti> roaksoax: i. e. narrowing down the crash and cause
[16:27] <infinity> rbasak: If you still think LP: #1434758 should be mentioned in the release notes, can you please add some text about it and close the bug?
[16:27] <ubottu> Launchpad bug 1434758 in Release Notes for Ubuntu "mysqld: errno: 24 - Too many open files" [Undecided,New] https://launchpad.net/bugs/1434758
[16:39] <pitti> roaksoax: I found a much faster/simpler non-machine crashing reproducer, in the bug now
[16:40] <pitti> roaksoax: you can check with systemd-analyze verify foo.service
[16:40] <roaksoax> pitti: oh nice!!
[16:40] <pitti> roaksoax: so that gives us a means to change the syntax until it stops crashing
[16:40] <pitti> roaksoax: as a local workaround to unblock you until this gets fixed properly
[16:41] <pitti> roaksoax: curiously it doesn't crash on my laptop
[16:43] <roaksoax> pitti: uhmmm interesting... so it is only happening on a VM?
[16:44] <pitti> roaksoax: unlikely, this is just a parser error; more likely related to different locale or what not, currently trying to find out
[16:44] <pitti> roaksoax: that's mostly relevant for creating an upstream unit test
[16:46] <pitti> roaksoax: got it
[16:46] <pitti> roaksoax: second-last line has a space after the \
[16:46] <roaksoax> pitti: ah!!
[16:46] <pitti> roaksoax: fix that, and it shold work
[16:46] <roaksoax> pitti: great! thanks!
[16:46] <pitti> roaksoax: but thanks for finding this, it'll make a nice test case
[16:47] <pitti> roaksoax: it shold just fail with "boo bad syntax"
[16:47] <roaksoax> pitti: althoguh, quite silly that systemd freaks out just for a whitespce :)
[16:47] <pitti> roaksoax: well, sure
[16:47] <pitti> roaksoax: it is broken shell either way, though, so it has to be fixed in the unit anyway
[16:47] <peppelakappa> hello guys, i'm doing a little research about some patch you use in the graphic stack. ubuntu seems to be the only distro out there that can use all the resolutions of a retina macbook pro out of the box. anyone have info about this?
[16:48] <pitti> roaksoax: I get it locally as well now
[16:53] <pitti> roaksoax: so, I'll write an upstream test case and get that fixed, thanks for pointing out; scary :)
[16:54] <roaksoax> pitti: hehe indeed... :) and someone complained about pustart.. and systemd freaks out for a white space :)
[16:56] <jtaylor> hi, is em1_1 a valid name for a nic device? because /etc/network/if-pre-up.d/vlan does not have a sed clause for that
[16:56] <jtaylor> and screws up setting up the vlan during boot :(
[17:21] <cjwatson> mhall119: Hi, it looks like when you registered https://launchpad.net/sprints/uos-1505 you didn't notice that we fixed https://bugs.launchpad.net/launchpad/+bug/1391281 a while back
[17:21] <ubottu> Launchpad bug 1391281 in Launchpad itself "Support UDS (UOS) virtual format for sprint attendance" [Low,Fix released]
[17:22] <cjwatson> mhall119: If you edit the sprint and uncheck "Is the sprint being held in a physical location?", then attendees won't have to answer the Physically/Remotely question
[17:38] <rbasak> infinity: will do
=== salem_ is now known as _salem
[22:04] <roaksoax> pitti: so invoke-rc.d no longer works for systemd units?
[22:06] <sarnold> roaksoax: I think the intention is for invoke-rc.d to work, see https://wiki.ubuntu.com/SystemdForUpstartUsers#Commands
[22:06] <roaksoax> sarnold: thanks!