[02:39] <darkxst> pitti, xnox, cjwatson: any idea what suddenly caused ppp to fail installing in ubuntu gnome livecd builds? http://pastebin.com/QcAZAZxC
[02:51] <Logan_> why don't we have locales-all in eglibc?
[02:52] <Logan_> nvm, found the answer
[04:36] <Unit193> xnox: I'd presume you'd like me to file a bug about zram-config needing a init script or systemd service?
[06:10] <xnox> Unit193: there is one already.
[06:10] <xnox> Unit193: systemd zram-config units should be added.
[06:13] <Unit193> xnox: I don't see them in bzr, but I'll trust you.  Sorry for the bother, then.
[06:15] <xnox> Unit193: i mean, there is a bug already =)
[06:15] <xnox> Unit193: i don't believe it's been implemented yet.
[06:16] <Unit193> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/zram-config/utopic/files/head:/debian/ Oh good, so I'm only silly for ignoring all bugs. :P
[06:46] <xnox> cjwatson: stgraber: pitti: so in ^ ubuntu-gnome case, ppp is configured before gdm is. And pppd-dns init.d script has Required-Start: gdm. Thus, the package should depend on gdm..... which seems wrong. Should the gdm move to X-Start-After instead?
[06:46] <xnox> (Should-start ?!)
[06:48] <xnox> oh, debian dropped gdm
[06:48] <xnox> let me merge / upload ppp
[06:48] <stgraber> that dependency seems wrong to begin with, why would pppd care about gdm?
[06:49] <ogra_> debian dropped gdm ? wow
[06:50] <ogra_> oh, the dependency you mean ... heh
[06:51] <xnox> stgraber: actually infinity added the gdm dep.... and change default start levels...
[06:51] <xnox> http://paste.ubuntu.com/7541969/
[06:52] <xnox> which seems a bit silly, given that dependencies have not been used in ubuntu, until now.
[06:53] <cjwatson> I wonder if that was a mismerge
[06:53] <cjwatson> It's not mentioned in the changelog, and perhaps it just hit when some files moved around
[06:53] <cjwatson>     - debian/ppp.pppd-dns: Update LSB header.
[06:53] <cjwatson> could easily have got stale
[06:54] <stgraber> looks like it, I don't see why anyone would voluntarily introduce that delta in Ubuntu
[06:56] <xnox> i uploaded dropping "gdm" dep only, for now (to unbreak every image type.... cause ppp seems to be seeded everywhere)
[06:56] <xnox> and will chat to infinity about merging ppp (or possibly syncing)
[06:57] <xnox> cjwatson: it also looks like it started to link against OpenSSL, yet there are gpl v2 plugins in ppp.
[06:57] <cjwatson> lalala
[06:58] <pitti> darkxst: gdm only got promoted to utopic this (early) morning, so I guess that image build didn't see that yet
[06:58] <xnox> cjwatson: well, openssl was a delta introduced in ubuntu?!
[06:58] <pitti> xnox: hm, why would ppp depend on gdm? that sounds like the wrong way around?
[06:58] <xnox> pitti: it's order dependant.
[06:59] <xnox> pitti: gnome image build is failing, because ppp is configured before gdm, yet ppp init.d script depends on gdm to be already enabled..... when it at all shouldn't really.
[06:59] <pitti> xnox: yeah, that init.d gdm dep sounds fishy
[07:00] <pitti> even if it *had* a reason to depend on a DM (can't think of any), it shouldn't hardcode a particular one
[07:00] <pitti> but ugh, this is network setup
[07:04] <infinity> xnox: That doesn't sound like the sort of thing I would have done on purpose.
[07:04] <pitti> Noskcaj, seb128: so gnome-icon-theme-symbolic 3.12 got synced yesterday, which is incompatible with our g-i-t 3.10; do we want to update g-i-t to 3.12 or delete the g-i-t-s from proposed?
[07:05] <seb128> pitti, is it really incompatible or is it the packaging enforcing the same serie?
[07:05] <pitti> seb128: I suppose it's mostly just the dependencies
[07:05] <seb128> or asked differently, can we tweak the depends
[07:05] <seb128> who did sync it?
[07:06] <seb128> Noskcaj?
[07:06] <cjwatson> xnox: if there are GPL plugins, then I can certainly see a case for either converting to GnuTLS, or for reverting the change in 2.4.5-5.1ubuntu2 and reopening bug 643417; but I haven't investigated
[07:06] <pitti> seb128: dholbach, sponsored for Noskcaj
[07:06] <infinity> xnox: Or at all...
[07:06] <pitti> seb128: but anyway, my question was rather if we generally move 3.12 wards
[07:06] <seb128> pitti, we do the usual "safe updates are fine, updates that are disruptives should be hold on in a first time"
[07:07] <infinity> xnox: When are you claiming this change crept in? :P
[07:08] <seb128> pitti, not sure how much they changed the icons, I know they are merging symbolic in the main theme, but that might be 3.13 only
[07:08] <mlankhorst> xkill
[07:08] <mlankhorst> oops
[07:10] <xnox> infinity: well, you were last merging it (and kept lsb-headers change that introduces gdm dep). the openssl build-dep was added after.
[07:20] <stgraber> xnox: you broke Ubuntu!
[07:28] <RAOF> pitti: colord tag debian/1.2.0-2 in collab-maint git should be ready to upload to sid.
[07:33] <infinity> xnox: Fair enough that I didn't drop the delta, but it's been there since jaunty, looks like.  Blame Keybuk. ;)
[07:43] <xnox> infinity: haha =)
[07:50] <brendand> Trying to boot and stuck on 'Stopping Click system level hooks'. Though i get the feeling this isn't the real problem
[07:50] <brendand> Any way i can get more verbose?
[07:50] <seb128> heh, I was about to ask about that as well
[07:50] <brendand> I already removed quiet from grub
[07:50] <seb128> xnox, pitti, infinity: have you bricked utopic? ;-)
[07:51] <brendand> :)
[07:51]  * brendand takes heart that it's not just him
[07:51] <pitti> right, being worked on
[07:51] <seb128> pitti, any workaround to boot my machine again?
[07:52] <brendand> seb128, safe mode
[07:52] <seb128> I want X
[07:52] <pitti> seb128: ironically, init=/lib/systemd/systemd
[07:52] <seb128> I'm in safe mode
[07:52] <brendand> seb128, start lightdm
[07:52] <seb128> brendand, my fs is ro in safe mode
[07:52] <seb128> pitti, danke
[07:52] <brendand> or do what pitti says
[07:52] <seb128> yeah, that's what I'm doing
[07:52] <brendand> Usually the right answer :)
[07:53] <brendand> seb128 - where do i set that option?
[07:53] <seb128> brendand, grub I guess
[07:54] <pitti> boot with holding the shift key, then edit Ubuntu
[07:54] <brendand> pitti - on the 'linux' line?
[07:55] <pitti> yes
[07:56] <brendand> brilliant!
[07:56] <seb128> pitti, works, danke!
[07:56] <brendand> Pitti - if i were in Malta i'd buy you all the beers
[07:56] <pitti> you mean kill us all because we broke utopic :)
[07:58] <brendand> pitti, well if you want to take the blame
[07:59] <brendand> pitti - then maybe there can be some poison in the beers :)
[08:01] <brendand> pitti, now i'm curious what happened
[08:06] <pitti> seb128, brendand: found an easier trick
[08:07] <brendand> pitti, seems pretty easy to me :) but tell me anyway
[08:08] <seb128> pitti, danke
[08:08] <brendand> pitti, ah rather than changing to systemd
[08:09] <pitti> either works
[08:09] <brendand> pitti, is one 'safer' than the other?
[08:09] <pitti> brendand: let's say I can't fully guarantee that the .legacy-bootordering trick does not have less obvious side effects, like starting some init.d scripts twice
[08:11] <brendand> pitti, i'll stick with systemd then
[08:11] <brendand> until that breaks too :)
[08:12] <darkxst> pitti I have no idea what you mean by gdm only got promoted to utopic? gdm has been there all along
[08:13] <pitti> darkxst: I mean from utopic-proposed
[08:14] <seb128> it's pitti's secret plan to push us to start using systemd!
[08:15] <Unit193> pitti: That pushed "Patch Pilots:" off the end, FYI.
[08:16] <darkxst> seb128, yes the merging of symbolic icons is only for 3.13
[08:17] <seb128> darkxst, is g-i-t-s working fine with g-i-t 3.10? are the 3.12 update changing anything obvious visually/likely to create issues?
[08:19] <pitti> Unit193: I know; -EDONTCARE for now :)
[08:19] <pitti> so, sysvinit uploaded with panic fix
[08:19] <Unit193> Sounds great. :)
[08:21] <darkxst> seb128, I haven't actually tested the 3.12 icon themes against 3.10, but I don't think there were any major changes for 3.12
[08:21] <pitti> seb128, brendand: please remember to remove /etc/init.d/.legacy-bootordering after you got the new sysv-rc
[08:22] <pitti> stgraber set the fast-track flag for that so that we don't have to wait for $WORLD autopkgtests
[08:22] <seb128> pitti, I didn't do that, just changed the init line ... do you want me to test that upload to see if it restores boot for me?
[08:22] <pitti> seb128: if you wish, sure
[08:22] <apw> pitti, can you check the current topic as /lib/systemd/system is a directory, and the kernel cannot boot that
[08:22] <pitti> apw: thakns
[08:22]  * pitti tosses apw a "d"
[08:22] <apw> pitti, :)
[08:24] <brendand> pitti, i didn't touch that. init= did the trick for me
[08:24] <pitti> brendand: right
[08:24] <pitti> I changed the topic to avoid people having to clean up that file
[08:24] <pitti> not quite the way I intended people to try systemd though :)
[08:24] <apw> pitti, so you _claim_
[08:24] <brendand> pitti, well the test passes !
[08:25] <pitti> so we already broke everyone by just re-syncing to Debian's sysvinit, which isn't even close to upstart/systemd
[08:29] <seb128> pitti, that sysvinit update fixes my boot, thanks!
[08:37] <pitti> I just sent an u-devel@ mail about it
[08:44] <ypwong> can't checkout unity-lens-files from bzr, anyone knows what's wrong? http://paste.ubuntu.com/7542487/
[09:09] <darkxst> pitti, seems like my main machine refuses to boot with systemd init :(
[09:12] <pitti> darkxst: so use the .legacy-bootordering workaround?
[09:14] <darkxst> pitti, I installed the sysv update which fixed things
[09:15] <darkxst> pitti, but I couldnt even get as far as a VT when booting with systemd ;(
[09:23] <ogra_> pitti, slangasek, i think we need to talk about the custom upstart helpers we have on the phone ... i.e. we have an upstart bridge that talks to the container to read/set android properties ... can systemd offer us the same ? who will have to port it etc ...
[09:25] <slangasek> ogra_: yes, and that is not on the roadmap for 14.10
[09:25] <brendand> is there any sort of documentation on actually using click (as a command line tool). like for creating click packages, installing them, etc
[09:27] <slangasek> brendand: 'man click'? :)
[09:28] <brendand> slangasek, sort of
[09:28] <ogra_> slangasek, oh, i thought there were plans to switch the default ?
[09:28] <brendand> slangasek, i'll see how far i can get with that
[09:28] <slangasek> ogra_: not for the phone
[09:28] <ogra_> would we have too special case the phone to keep upstart ?
[09:28] <ogra_> *to
[09:29] <ogra_> (we currently just inherit ubuntu-minimal)
[09:29] <slangasek> ogra_: we're only switching to systemd by default opportunistically in 14.10 if it's stable, and not for the phone because it would be disruptive to RTM
[09:30] <ogra_> ah, super then ...
[09:30] <ogra_> thanks !
[09:56] <LocutusOfBorg1> can anybody please retry this one? https://launchpad.net/ubuntu/+source/sandboxgamemaker/2.7.1+dfsg-2build2/+build/6044192
[09:57] <LocutusOfBorg1> seems blocking the libenet7 transition
[09:57] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/cube2/0.0.20130203+dfsg-1build1/+build/6044206
[10:19] <Saviq> pitti, THANK YOU! (re: sysv-rc)
[11:31] <goarilla> can someone tell me what I need to do to recreate the /isolinux/bootlogo gfxboot archive
[11:34] <pitti> RAOF: hmm - I just see 1.2.0-1 in colord git, but that's already in exp?
[11:35] <cjwatson> goarilla: That's built by the gfxboot-theme-ubuntu source package - "make installdir" there
[11:35] <BluesKaj> ok, here's a list of the problem dependencies on 14.10, http://privatepaste.com/794db390e0, wonder if any devs are looking at this?
[12:31] <pitti> RAOF: uploaded
[12:38] <RAOF> pitti: Huh. Experimental?
[12:38] <pitti> RAOF: oh sorry; the previous one I looked at was against experimental and I didn't look hard enough at the new changelog
[12:39] <pitti> RAOF: so, -3 then? :-/
[12:39] <RAOF> pitti: I guess so :)
[12:39] <RAOF> Would you like to do that?
[12:39] <pitti> RAOF: can do
[12:51] <BluesKaj> pitti, I'm looking at your post in the devel forum https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038333.html, but i'm not having boot problems, only upgrade problems, this what gets written to /var/lib/insserv/run-20140529T0840.log ,  http://privatepaste.com/ac2b0e2233 , any suggestions?
[12:53] <BluesKaj> pitti, this the dependency error, http://privatepaste.com/794db390e0
[13:00] <pitti> BluesKaj: that was fixed in udev 204-10ubuntu7, do you have that?
[13:03] <pitti> BluesKaj: right, your second pastebin shows it's ubuntu6
[13:07] <BluesKaj> pitti, muon shows I have 204-10ubuntu5 installed, but upgradeable
[13:08] <pitti> xnox: pad.ubuntu.com/init.d-task-check
[13:08] <BluesKaj> pitti, upgrade it or will it fail ?
[13:09] <pitti> BluesKaj: upgrade shold be fine
[13:09] <pitti> RAOF: -3 uploaded FTR
[13:09] <RAOF> pitti: Much ta
[13:10] <BluesKaj> pitti, it won't mark for upgrade, fails
[13:14] <BluesKaj> pitti, looks like I'm caught in dependency hell
[13:18] <pitti> BluesKaj: hang on, I'm just fixing someone else's box with that problem
[13:20] <BluesKaj> ok pitti np, thanks {)
[13:21] <pitti> BluesKaj: so what I did here was to apt-get download libudev1 udev, then sudo dpkg -i those, then run apt-get -f install a few times
[13:37] <BluesKaj> pitti, not installing dpkg: error processing package initscripts (--configure)
[13:40] <BluesKaj> same with sysv-rc systemd and libpam-systemd:amd64 , ran -f install several times after dpkg install
[13:53] <xnox> infinity: hey, is procps installed in the buildds?
[13:55] <pitti> xnox: killed from -proposed
[13:55] <xnox> pitti: tah.
[14:03] <BluesKaj> looks like I'm jammed up in the dependency vicious cycle :\, pitti afraid the udev and libudev1 wouldn't install
[14:04] <pitti> BluesKaj: you need to do apt-get download / dpkg -i, apt won't help :/
[14:04] <BluesKaj> I used dpkg -i
[14:05] <shadeslayer> pitti: is utopic broken again ? :(
[14:05] <shadeslayer> pitti: http://paste.kde.org/phcz8yo9s
[14:05] <pitti> shadeslayer: not as long as you have udev >= ubuntu7
[14:06]  * shadeslayer checks
[14:06] <pitti> shadeslayer: that's -proposed, procps ubuntu4 just got removed
[14:06] <pitti> shadeslayer: yes, ubuntu4 is known-broken
[14:06] <shadeslayer> ok
[14:06] <shadeslayer> pitti: ok, I'm using proposed in my pbuilder
[14:06] <pitti> shadeslayer: should clear up in some 20 mins
[14:07] <shadeslayer> cool :)
[14:07] <rsalveti> pitti: xnox: wgrant: chroot problems again https://launchpadlibrarian.net/176554996/buildlog_ubuntu-utopic-amd64.hud_13.10.1%2B14.10.20140529.1-0ubuntu1_CHROOTWAIT.txt.gz
[14:08] <rsalveti> is that known?
[14:08] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#procps
[14:08] <xnox> rsalveti: we know, it's fixed, waiting for archive.
[14:08] <rsalveti> xnox: great, thanks
[14:08] <xnox> rsalveti: "fixed" procps is removed from the archive, waiting for publishing cycle.
[14:12] <BluesKaj> pitti, http://privatepaste.com/ea827304ed
[14:13] <xnox> wgrant: well, pitti removed the package from the archive already
[14:13] <wgrant> We're getting good at that :)
[14:14] <xnox> wgrant: =))))
[14:14] <wgrant> Testing obscure Soyuz corner-cases!
[14:14] <wgrant> It's just QA.
[14:14] <xnox> wgrant: adt testing has caught it, so it wouldn't migrate to -release and break either system or buildds permamentaly.
[14:14] <wgrant> Aw :(
[14:14] <xnox> wgrant: no surgeries required this time around
[14:15] <wgrant> :(
[14:15] <xnox> slangasek: it wasn't dependency problem, it was the fact that in TARGETS the name of the "script/job" was listed, even though it has no dependencies and it's a task in upstart.
[14:15] <slangasek> xnox: ah.  Well, insserv knows nothing of upstart
[14:15] <xnox> slangasek: upstart-tasks with no reverse-dependencies should be in TARGETS, since unlike debian we do not support sysv-init boot.
[14:16] <slangasek> insserv and startpar are two separate pieces
[14:16] <xnox> (reverse-initd-dependencies)
[14:16] <xnox> slangasek: hm. ok.
[14:16] <xnox> slangasek: let me look into startpar.
[14:16] <BluesKaj> yup, and I'm stuck in between
[14:17] <xnox> slangasek: the alternative is to remove upstart-task jobs, if there is an init.d script..... and just use init.d script </troll>
[14:17] <mdeslaur> xnox: so...when a package only has an upstart job, and the user is using systemd, the debhelper stuff explodes when invoke-rc.d is run...
[14:17] <xnox> mdeslaur: fixed in ubuntu6 debhelper upload + needs rebuilds.
[14:18] <xnox> mdeslaur: e.g. kernel needs rebuild because of linux-cloud-tools-common
[14:19] <mdeslaur> xnox: that fix won't work
[14:20] <mdeslaur> well wait, let me look at it again
[14:21] <xnox> mdeslaur: if, and only if init.d script is exucatable -> run update-rc.d
[14:21] <xnox> mdeslaur: invoke-rc.d can be run against any of upstart/sysvinit/systemd
[14:21] <xnox> (and well should be run)
[14:22] <mdeslaur> xnox: if there's only an upstart job, and systemd is running, invoke-rc.d gets called with start, but then fails because there is no systemd job
[14:22] <xnox> mdeslaur: yes.
[14:22] <xnox> mdeslaur: that's intentional.
[14:23] <mdeslaur> uhm, why?
[14:23] <slangasek> mdeslaur: the package shouldn't be considered configured until the service is started; the service cannot be started because it's not supported on the running init
[14:23] <xnox> mdeslaur: well, not intentional. but current status quo, with the fact that systemd migration has not been complete and ubuntu, unlike debian, has allowed adding upstart jobs without shipping an init.d script.
[14:23] <slangasek> so it needs to be fixed to integrate
[14:23] <xnox> mdeslaur: the fix is to either ship init.d script + upstart job, or to ship init.d script + systemd + upstart
[14:24] <mdeslaur> slangasek, xnox: ah, ok, thanks
[14:24] <xnox> mdeslaur: currently we don't support shipping just systemd units or (systemd unit + upstart job)
[14:25] <xnox> rsalveti: shadeslayer: chroots should be fine now.
[14:25] <sarnold> love it. to move from one init to another init we need to support a third init that we dropped absolute yonks ago..
[14:26] <slangasek> I'm confused why that's a requirement
[14:26] <slangasek> it's a requirement for Debian; shouldn't be for Ubuntu
[14:26] <xnox> sarnold: we never dropped it absolutely..... upstart execs rc at both boot, each of the runlevel, and shutdown.
[14:26] <xnox> slangasek: at least dh_installinit doesn't support it at the moment.
[14:26] <mdeslaur> sarnold: we can ship upstart + systemd
[14:26] <xnox> slangasek: although maybe it's achieved with dh_systemd, not sure.
[14:27] <xnox> mdeslaur: i didn't try doing that yet.
[14:27] <slangasek> xnox: which piece is unsupported?
[14:27] <mdeslaur> oh, sorry, yeah, that's what xnox said
[14:27] <slangasek> update-rc.d not being called?
[14:27] <xnox> slangasek: invoke-rc.d start is not called by dh_installinit alone.
[14:27] <xnox> slangasek: unless one must use dh_systemd, which i am not familiar with, and maybe that does something else.....
[14:28] <shadeslayer> xnox: still waiting for sync to mirror :)
[14:28] <slangasek> mm
[14:30] <xnox> sarnold: rather we try to support both upstart & systemd at the same time. And then involves extra work to integrate startpar.
[14:31] <mdeslaur> *grumble*
[14:32] <sarnold> xnox: I'm sorry, I wasn't trying to be mean, I surely haven't looked at it as much as you, it just caught my fancy that we've got to add an old sysv script to make this transition happen..
[14:32] <ogra_> mdeslaur, why do you grumble ? at least there are no security issues on a system that does not boot
[14:34] <xnox> sarnold: it is hallarious. In a way migration to upstart never actually was completed =) thus it's all just one big multi-year transition =)))))))))))))))))))))
[14:34] <mdeslaur> ogra_: I'll just symlink my init.d script to /sbin/halt
[14:34] <ogra_> +1
[14:35] <xnox> mdeslaur: emacs; /sbin/halt =))))
[14:38] <pitti> BluesKaj: well yes, dpkg -i takes a .deb file, not a package name; so sudo dpkg -i libudev1_*.deb
[14:38] <ogra_> xnox, you sure that shouldnt be systemd-emacs ?
[14:39] <mdeslaur> ogra_: you better be touching wood right now
[15:23] <hallyn> ok, only took me 3 hours to give up on trying to get normal login to work by hacking upstart scripts, and just hack tty[2-5].conf to start on local-filesystems
[15:25] <hallyn> ah goodie, so now that i can log in i can read email and see pitti's email :)
[15:31] <hallyn> really i don't know why /etc/ttyn.conf don't always start on local-filesystems.  think i'll keep it that way here
[15:34] <BluesKaj> pitti, thanks for your help, there were some rc.d warnings, but all sems fine now :)
[15:36] <BluesKaj> on 2 machines btw
[16:34] <hallyn> so is the fact that today lxc upgrades keep complaining that /etc/init.d/lxc-instance does not exist also related to the utopic init scrits change?
[16:34] <hallyn> or did i just mess myself up somehow
[16:34] <hallyn> oh, perhaps related to what xnox said above
[16:35] <slangasek> hallyn: yes, lxc needs a no-change rebuild w/ current debhelper
[16:35] <hallyn> do i need to push that as a new source version, or can that be triggered another way?
[16:36] <hallyn> oh actually i get mine from the ubuntu-lxc ppa anyway.  stgraber can you force a rebuild there?
[16:36] <hallyn> i'll see if the version in archive actually dtrt
[16:50] <rbasak> hallyn: if binaries have been published in the archive (doesn't matter which pocket), then you need to do a new upload with a bumped version number. "dch -R" does the right thing I think.
[16:51] <rbasak> (if you need to)
[16:53] <rbasak> The same applies in a given PPA, too. You can't have new rebuilt binaries with the same version as previously published binaries in a given archive.
[16:57] <hallyn> yeah i know how to do it tha tway, seemed plausible there'd be some switch which a few people could pull when it needed to be done at scale :)
[17:00] <hallyn> though actually -R doesn't seem to dtrt...  (will do it manually)
[17:05] <rbasak> At scale: "dch -R" in a for loop is what I think everyone does :)
[17:30] <hallyn> rbasak: you ppl trusting your gpg agnets... :)
[17:30] <hallyn> rbasak: i do wonder why dch -R didn't work for me.  it just bumped the version # as usual
[17:30] <hallyn> i mean, i prefer to choose by hand anyway, just wondering...
[17:31] <rbasak> hallyn: AIUI, for a no change rebuild of a synced package, it should append build1 (or bump to build2, etc). And for a package with an Ubuntu delta, then the ubuntu1 will get bumped to ubuntu2 etc.
[17:31] <rbasak> Then everything else (eg. autosyncs) behave right
[17:32] <rbasak> So maybe it needed to just bump the version, if you already had an Ubuntu delta?
[17:37] <hallyn> hm
[17:38] <hallyn> i guess that makes sense, except it's not as informative...  but thx
[20:22] <Noskcaj_> My 14.10 install is now stuck at the
[20:22] <Noskcaj_> "checking disk" part of startup
[20:23] <Noskcaj_> Is this a known issue?
[20:25] <sarnold> Noskcaj_: seen this? https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038333.html
[20:26] <Noskcaj_> sarnold: Yeah, I've already tried the first workaround, wasn't sure it was related
[20:26] <sarnold> Noskcaj_: ah, okay :)
[20:36] <Noskcaj_> It says boot into resuce mode. How do you do that?
[20:37] <slangasek> shift at the grub menu, choose the rescue option from the advanced menu
[20:38] <sarnold> if your grub doesn't have it, add recovery nomodeset to the kernel command line
[20:39] <Noskcaj_> ok
[20:39] <Noskcaj_> recovery mode?
[21:37] <Noskcaj> jpds, There's a new upstream git change for efitools, is it worth packaging? http://git.kernel.org/cgit/linux/kernel/git/jejb/efitools.git/commit/?id=c33fc28e6be00ac0bfae7fcff48170830a4730d8
[23:24] <Unit193> Forgot to put a dest in dput again, I need to change 'ubuntu' from being default. >_>
[23:26] <fdafweaf> The Stats page for myapps.developer.ubuntu.com indicates that i have 17 downloads of my app, and it shows a pie chart breakdown by country, but the line graph at the top of the page doesn't have any data in it
[23:26] <fdafweaf> Is that correct behavior?
[23:58] <Logan_> Unit193: I'm disappointed in you