[00:00] <nacc> rbasak: sure
[00:00]  * rbasak has a broken '' key. ime for a new lapop?
[00:00] <sarnold> your 't' key doesn't look so good either
[00:01] <rbasak> Like I said :-P
[00:03] <nacc> rbasak: LP: #1686859 filed
[00:09] <rbasak> Thanks!
[05:07] <ScottK> rbasak: Thanks.  Not sure if I should LOL or cry.
[07:58] <infinity> mvo: *poke*
[07:58] <infinity> mvo: I see a bug in those snapd uploads already.
[07:58] <mvo> infinity: meh
[07:58] <mvo> infinity: tell me more
[07:58] <infinity> mvo: Unless dpkg-gencontrol is smarter than I am...
[07:58] <infinity> mvo: Built-Using: ${Built-Using} ${misc:Built-Using}
[07:58] <infinity> mvo: That looks like it'll be missing a comma.
[07:59] <infinity> Oh.  Unless the way you create the first adds a trailing comma.
[08:00] <infinity> mvo: Nevermind.  It does.
[08:00] <infinity> mvo: I didn't read your make closely enough. :P
[08:00] <mvo> infinity: thanks for the careful check!
[08:00] <mvo> infinity: I tested this but was worried for a moment that I forgot something here
[08:02] <infinity> mvo: Though, that Built-Using might be a slight lie on Debian, where seccomp is disabled. But that's a less interesting issue.
[08:03] <infinity> mvo: You might want to set VENDOR_ARGS and BUILT_USING_PACKAGES in the same if/else/endif blocks to keep them matching, but indeed not relevant for the Ubuntu SRUs.
[08:10] <mvo> infinity: indeed, let me look at this. thank you!
[08:11] <infinity> mvo: Also wondering why you're making your own life difficult by having Ubuntu and everyone else differ on the snap-confine apparmor profile name?
[08:12] <infinity> mvo: I mean, sure, it was an Ubuntu oops that made us rename it, but... Divergence is gross.
[08:16] <mvo> infinity: good point, this debian packaging is mostly for our tests currently but there is really no need to diverge. something for morphis_ to check I think :)
[08:19] <mvo> infinity: I pushed a branch for the built-using, lets see if the debian tests are still happy
[08:43] <morphis_> mvo: tell me more about the different names of the apparmor profiles, you mean the one with .real and the one without?
[08:44] <mvo> morphis_: yeah, infinity pointed out that we do not need to diverge between ubuntu and debian
[08:46] <morphis_> wasn't really aware that we do that
[08:46] <morphis_> but have an item on my list to check how different we're in terms of packaging for debian and ubuntu
[09:07] <juliank> xnox: I know you wanted to play with systemctl is-active, but I did a further try with flock inside of the script, and that seems to work nicely (well, apart from it now requiring bash...): https://paste.ubuntu.com/24471873/
[09:07] <juliank> The script acquires the lock at the start, or waits an hour and if it can't acquire fails
[09:08] <juliank> For the long running processes, I close the fd so they don't leak into it (who knows what these start)
[09:17] <juliank> (It's somewhat unclear to me if there's a race condition somewhere if we just check if the other unit is active in ExecStartPre)
[10:54] <rbasak> xnox: are we planning on doing the openssl transition this cycle?
[10:57] <xnox> rbasak, sigh, that thing again.
[10:57] <xnox> rbasak, last time the argument was we don't want two ssl's in main; and at the time neither openssh or apache were ported. let's see what the current state of things is.
[10:57] <xnox> i think we have to do it before 18.04
[10:58] <xnox> i see that both of those are still 1.0
[10:59] <xnox> then again those things might never migrate =/
[11:02] <xnox> i hope there is like a new LTS release, cause 1.1 is not; and 1.0 is until end of 2019 only.
[11:06] <rbasak> xnox: thanks. To be clear, I'm not pushing. I was just asked whether to expect it so we can be ready to fix things.
[11:11] <xnox> rbasak, i'm inclined to say not this cycle.
[11:11] <xnox> mdeslaur, do you want openssl 1.1 yet? loads of key things are still not fixed....
[11:11] <mdeslaur> what I don't want is two openssls
[11:12] <mdeslaur> so if there's still stuff that doesn't work with 1.1, I suggest we wait
[11:12] <xnox> ... in main
[11:12] <xnox> or everywhere? because it's well openssl.
[11:12] <mdeslaur> I would suggest everywhere...last time we had 0.9.x in universe, and people kept using it and bugging us to fix it
[11:13] <xnox> OMG, there was openssl before 1.0? =/
[11:13]  * xnox wonders if i was alive or not.
[11:13] <mdeslaur> xnox: you were 4 at the time
[11:14] <mdeslaur> xnox: I also worry about the fact that 1.1 isn't an LTS release
[11:14] <mdeslaur> and 1.0 will be supported longer than 1.1 :P
[11:15] <rbasak> Yeah keeping one of a thing in main and another of the same thing in universe has never worked out well.
[11:15] <rbasak> Actually, that's perhaps not true with things like Python.
[11:16] <xnox> rbasak, will nova be ported to python3 and will we be able to have python2 in universe in 18.04?
[11:16] <mdeslaur> I definitely need 1.1 or higher for the LTS though
[11:16] <rbasak> No idea, sorry. I don't work on the openstack team.
[11:16] <mdeslaur> s/I/we/
[11:17] <xnox> true.
[11:17] <xnox> bzr, python2, gtk2, qt4, upstart, openssl1.0 -> oh i wish we can kill all of those
[11:57] <infinity> mdeslaur: It might be worth someone trying to get OpenSSL upstream to commit to their next LTS Very Soon.  They claim they're to do so every 4 years, and the last was 2014, so the time is nigh.
[11:58] <mdeslaur> infinity: yeah
[11:58] <infinity> mdeslaur: If I was a betting man, I'd guess 1.1.1 will be the next LTS, but no one really knows for sure.
[11:59] <mdeslaur> at least we'd know what to expect
[11:59] <infinity> mdeslaur: If it's 1.1.x or 1.2, I imagine we can roll with it, but if we decide to push 1.1 and then they say "surprise, 1.0.x is LTSing again!", we'll be in a world of hurt.
[12:00] <mdeslaur> definitely
[12:05] <infinity> xnox: As for gtk2 and qt4, I predict they'll die around the time gtk6 and qt8 are released. :P
[12:05] <infinity> xnox: So, right around the end of the UNIX epoch.
[12:05] <mdeslaur> it's quite nice that we dropped the gtk3 irc client in favour of the gtk2 irc client
[12:06] <infinity> People use graphical IRC clients?
[12:06] <infinity> Savages.
[12:06] <mdeslaur> infinity: and mice!
[12:06] <infinity> mdeslaur: Aren't mice exclusively used to control first person shooters?
[12:06] <mdeslaur> you can plug a mouse into a PS4?
[12:07] <infinity> You can play FPSes properly on a console?
[12:07] <ogra_> asciidoom!
[12:07] <infinity> (Though, yes, you can attach a mouse to a PS4 or Xbone, if you're so inclined)
[12:27] <Skuggen> I think some publishers asked the console makers for ways to prevent it, though, since it gives a competetive advantage :)
[15:11] <rfleming> Greetings smart Ubuntu people.
[15:13] <rfleming> I am in need of your help.  I am trying to find where gvfsd-fuse is called so I can change the option to allow_root
[15:29] <lamont> rbasak: sad things are sad
[15:29] <lamont> rbasak: also, wtf hahaha
[15:30] <rbasak> :)
[15:37] <dpb1> bdmurray: hey https://bugs.launchpad.net/cloud-init/+bug/1676908 for that bug, what gives the ACL for accept/decline on those nominate series tasks?
[15:39] <bdmurray> dpb1: Being able to upload the package or being a member of the poorly named ubuntu-release-nominators team.
[15:40] <dpb1> bdmurray: that's per-package-upload rights for cloud-init specifically, or 'ubuntu-release-nominators'
[15:40] <dpb1> bdmurray: ?
[15:41] <bdmurray> dpb1: being able to upload the package at all (as a core-dev I could accept the nominator) or being a member of that ubuntu-release-nominators team.
[15:41] <dpb1> k
[15:41] <dpb1> thx bdmurray
[15:42] <bdmurray> dpb1: The SRU tools automatically add / accept release tasks.
[15:42] <dpb1> bdmurray: sru developer permission probably required there, right?
[15:43] <bdmurray> dpb1: I don't know why you want to have the release tasks approved but if it is for the SRU process my point is that'll get handled automatically by the SRU team when they approve the SRU.
[15:44] <dpb1> bdmurray: ok, so it's fine to leave them unaccepted
[15:44] <dpb1> bdmurray: for prepping an sru
[15:44] <bdmurray> dpb1: Yes.
[15:45] <dpb1> great, thanks.
[17:45] <nacc> Odd_Bloke: also note that since gce-compute-image-packages isn't in our automtic import list, you're not racing the importer for it :)
[17:45] <nacc> Odd_Bloke: i think you got some feedback, did you update your MR?
[17:47] <Odd_Bloke> nacc: Yep, I did.
[17:47] <nacc> Odd_Bloke: ok, i can pull it in
[17:50] <Odd_Bloke> nacc: Thanks!
[17:50] <Odd_Bloke> Just in time for another import run, too, I think. :)
[17:51] <nacc> Odd_Bloke: oh i see, maybe rbasak already did it? https://git.launchpad.net/~usd-import-team/ubuntu/+source/gce-compute-image-packages/tag/?id=upload/20160930-0ubuntu6_14.04.0
[17:51] <Odd_Bloke> Oh, maybe.
[17:51] <nacc> ok, i'll run the import then and it should pick it up
[17:52] <Odd_Bloke> Oh, yes, he did.
[17:54] <nacc> Odd_Bloke: https://git.launchpad.net/~usd-import-team/ubuntu/+source/gce-compute-image-packages/log/?h=applied/ubuntu/trusty-devel
[17:54] <nacc> Odd_Bloke: and your tagged upload is now part of the history :)
[17:59] <Odd_Bloke> \o/
[17:59] <Odd_Bloke> Thanks!
[18:00] <nacc> Odd_Bloke: np
[18:01] <nacc> LocutusOfBorg: are you ok if i merge libguestfs?
[18:14] <jbicha> fossfreedom: why doesn't Budgie want tracker any more?
[18:15] <fossfreedom> it is a memory whore and people have been complaining of high CPU usage.
[18:17] <jbicha> because of how Ubuntu metapackages work, it will still be installed for users who upgrade
[18:19] <fossfreedom> hmm - will have to cover via the release notes then.
[18:20] <jbicha> see my commit msg for a few benefits to having tracker installed:
[18:20] <jbicha> https://bazaar.launchpad.net/~ubuntu-desktop/nautilus/ubuntu/revision/536
[18:21] <jbicha> the Ubuntu Desktop is undecided about whether to include tracker by default
[18:22] <jbicha> it would be helpful if we could measure how badly it abuses CPU and RAM
[18:23] <jbicha> tracker doesn't seem to be misbehaving on my computer
[18:24] <fossfreedom> various people have mentioned that the idle RAM dropped from 850MB to approx 600-650.  CPU not sure of - other than a couple of users who mentioned removal of tracker stopped the computer running at close 100% for several minutes.  I didnt though ask what they actually had on their computers and their setup
[18:26] <jbicha> I think it's using ~150MB RAM here according to gnome-system-monitor
[18:27] <fossfreedom> k - that makes sense then with the observation.
[18:33] <jbicha> I'm just used to some websites using more RAM than that :|
[18:36] <fossfreedom> it doesnt bother me given my setup.  I'm aware of our community though who are using lower end laptops and older computers though.  So perhaps more sensitive to stuff running
[18:38] <jbicha> I can understand gnome-documents not being in the default install because it's an unusual app but I think gnome-photos is decent and should get better in the future
[18:39] <fossfreedom> difficult to justify tracker for one app though.
[18:39] <fossfreedom> "if (g_strcmp0(g_getenv("XDG_CURRENT_DESKTOP"), "GNOME")" --> so those bits in the commit are specific to GNOME-Shell
[18:42] <jbicha> that commit dropped a patch that made nautilus work differently when run outside of "GNOME" (in Unity)
[18:42] <fossfreedom> ah
[18:51] <nacc> rbasak: fyi, i think src:supermin 4.1.3-1 also triggers the empty dir warning
[20:46] <LocutusOfBorg> nacc, I am, but infinity probably not
[20:46] <LocutusOfBorg> he don't want an ocaml transition
[20:47] <LocutusOfBorg> (he didn't want it last time I asked IIRC, fox yakkety or zesty)
[20:52] <LocutusOfBorg> I would start with an ocaml merge and then do libguestfs and ben
[20:52] <LocutusOfBorg> I can do it tomorrow if nobody objects
[20:53] <LocutusOfBorg> Laney, can I steal src:ben merge?
[20:56] <LocutusOfBorg> (uploaded on ppa:costamagnagianfranco/locutusofborg-ppa)
[22:36] <nacc> LocutusOfBorg: ack, i'll just fix it up with a rebuild then
[22:42] <nacc> rbasak: apparmor too
[22:43] <sarnold> ?
[22:43] <nacc> sarnold: empty directories in the srcpkg?
[22:43] <sarnold> nacc: do we do that?
[22:43] <nacc> sarnold: it confuses git -- 2.11.0-2ubuntu4 apparently has one
[22:43] <nacc> sarnold: rather than importing it, we're flagging it as an error until we have a workaround
[22:44] <nacc> sarnold: let me check locally
[22:45] <nacc> sarnold: http://paste.ubuntu.com/24475776/
[22:45] <nacc> sarnold: the output of `find . -type d -empty`
[22:46] <nacc> sarnold: since those are in the orig tarball, dpkg-buildpacakge will complain if we delete them via our importer's build
[22:46] <nacc> sarnold: but i think we still aren't storing them in our git representation of the (git-)tree
[22:46] <nacc> sarnold: nothing for you to worry about :)
[22:47] <sarnold> curious desktop/ is empty in my local checkout too
[22:47] <sarnold> as is namespace/
[22:47] <nacc> sarnold: yeah, so `pull-lp-source` etc. can do fine with it
[22:48] <nacc> sarnold: is your local checkout from a git repository?
[22:48] <sarnold> nacc: worse, bzr. :/
[22:48] <nacc> sarnold: ah ok -- bzr may be able to represent those changes, i'm not sure
[22:48] <nacc> sarnold: and we can do it with git, we just don't currently in the importer, so we've got a bug filed (for dgit as well)
[22:56] <slangasek> yes, bzr does represent empty dirs
[22:56] <nacc> slangasek: thanks for confirming


 @RazPi isn't that the point of atomic operations?  Like AtomicBoolean, or sync?  I've never had a problem with AtomicBoolean.
 @AdamOutler I'm not quite sure I haven't read into atomic operations too much, I think those are about shared memory? A lot of what I've read recently in concurrency is that copying variables is king. Not relying on anything but copying and message passing. Which has some overhead initially but the benefit is clearer at scale.
 So much stress is put on immutable variables
 Atomic Operations are generally used on shared variables.  There is a locking-wait mechanism which locks the variable for reading, then unlocks it after the result is returned.  The same occurs for writing.  This way when two tasks attempt to access the same resource, only one will obtain it.  They may share states by using Atomic Operations.
 https://en.wikipedia.org/wiki/Linearizability
 Ohh ok, so yeah, a lot of these languages geared towards concurrency seem to focus on avoiding locking altogether by making copies of variables, and not allowing state to change. So you have to destroy and create a new state each time.
 oh, like making a variable final before starting a task?
 I believe so, making a variable final or immutable means that you can do multiple operations on any cpu or any machine since there's no state to worry about, but it does mean you have to approach it differently
 So, I had a problem when designing CASUAL.  I had to start ADB, Initialize the process handlers, start the scripting engine, deploy zip files and play an audio sound.   All of these were "required" before the button was able to be initialized.  My solution was to create a custom AtomicThread object array and check hasStarted and hasCompleted which were atomicBooleans.  This allowed the state to be shared
[02:35] <floridagram-bot> between threads and worked very nicely.
 Once the threads had all started and all completed, they were done and the checking process could continue.
 Ooh, iirc things like that expand well into a finite state machine
 I hit that problem in webdev in python at some point doing a ton of permission checks
 That's when I started realizing that programming paradigms in general were facades over a finite state machine, and that you could abstract fsm's over and over again to cover other problem domains that represented an fsm
 android has big finite state machine graph for its media player I believe?
 Yeah, as long as you can enumerate the states of an object, you can control it.  It's when they aren't enumerated that they become problematic.
 That's why it's best to start at a drawing board, or define an API, or at least skeleton an app before actually creating it.  The worst problems occur when you are like "oh crap, let me just take care of this problem I never thought about...".  Suddenly there's a bunch more problems and they all don't really work well together.
 I don't know if this is appropriate for this case but thought I'd throw it out there
 I always "//TODO:" any oh crap moments.  Then come back and reevaluate later to check if it was actually the right way to do it. 👍
 I have a lot of TODO's to revisit :(
 I literally wrote in a git history once "I'm sorry for everything after this commit."
 hehe.  use a drawing board man.
 hahahhahaa
 xD
 It's better than some of the stuff I've seen from OEMs.  i'm sure.
 we're talking about 8-figure hodgepodge operations here.
 @_@
 I know... right?  Sometimes they share code samples with us.  I try not to read them because it makes me liable if I comment.  But sometimes they're really bad.
 I can't give examples, but sometimes they're really bad.
 Here's some bad code I can give an example about... nice and neutral, Google code, written really poorly. https://www.youtube.com/watch?v=qdglKxxXO8M
 :D
 XD
 Nice intro
 That is one of my favorite intros.
 I guess it was the other one with the ADK with bluetooth that was really bad code.
 https://www.youtube.com/watch?v=C1PCFE1LlC4
 Those were some of my worst performing videos for the channel, but were also some of my favorite to make.  they didn't deal with mobile devices though, so they didn't translate to the captive audience well.
 @ahoneybun, That has been a thing for a while, I want a SNES classic simply for the bragging rights - and the unreleased Starfox game that will be launching on there
 Yeah that's kinda a dick more to have an unreleased game as a selling point
 @ahoneybun, Its business - and a smart move on Nintendo's part IMHO as it will drive demand to that console instead of knock-offs, emulation and other things.
 Yea
 A dick move and a smart business move done nesscerily have to be mutually exclusive.
[21:08] <maxolasersquad> ++
 I don't see how it's a dick move though, isn't it more or less like you're buying a new game?
 I have unreleased CASUALs if anyone is interested in donating.
 @AdamOutler, Honestly I do believe you on that
 Yep, I need $100 in donations and at least 1000 thanks before I release.
 I'm kidding. I can't.  But that's typical XDA-Kiddo behavior.
 Speaking of thanks, I'm 124 thanks away from maxing out my Thanks Meter.
 Can't read; too low res.
 That's like nothing.
 I integrated a T-Mobile Softphone, Plex and my OpenVPN Management UI into the NextCloud Client


[00:19] <infinity> Oh, thank god, I was worried we might go a whole month without a poppler ABI bump.
[00:20] <infinity> I wonder if maybe we should rename PlusOneMaint to PopplerAndEDSMaint.
[00:22] <doko> just staff two people from -desktop for the team, there's not much to do for -foundations
[00:23] <infinity> I dunno, we had a nasty poppler API transition earlier this cycle, where the best porting work was done by a member of the kernel team.
[00:23] <infinity> Clearly, we need more kernel people.
[08:46] <psivaa> Just in case it has not been noticed, the report.html for quantal server contains 9 packages, though they are not affecting our daily automated tests
[08:50] <xnox> psivaa: I am curious which report do you mean. Can you please give a full link?
[08:50] <psivaa> xnox, http://cdimage.ubuntu.com/ubuntu-server/daily/current/report.html
[08:51] <xnox> I see. cool thanks.
[08:51] <psivaa> xnox, just for the information though
[09:25] <cjwatson> psivaa: yep.  they're all listed on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html, so it isn't an image build problem.
[09:26] <cjwatson> psivaa: I suspect that http://people.canonical.com/~ubuntu-archive/component-mismatches.txt explains a fair few of them
[09:27] <cjwatson> Probably ignorable for now.
[09:31] <Laney> infinity: doko_: Is it unreasonable to expect the uploader to care about transitions they start?
[09:35] <Laney> He did do some, actually.
[09:39] <psivaa> cjwatson, i see the connection now, thanks, will check them as well in the future.
[11:38] <sil2100> Hello!
[11:38] <sil2100> I have a new UIFe proposition
[11:39] <sil2100> https://bugs.launchpad.net/unity-asset-pool/+bug/1049594 <- would be grateful if someone could check it out in their free time :)
[11:39] <ubot2> Launchpad bug 1049594 in unity-asset-pool "[UIFe] Unity lens category icons need update" [Undecided,New]
[11:39] <sil2100> Thanks!
[12:24] <knome> cjwatson, i hear indicator-sound is still stuck in NEW (re: bug 1048217). any specific reason?
[12:24] <ubot2> Launchpad bug 1048217 in ubuntu "[FFe] Re-introduce indicator-sound-gtk2/ido-gtk2" [Undecided,Triaged] https://launchpad.net/bugs/1048217
[12:24] <jbicha> any idea what this "undefined video mode" error is, it shows up after the isolinux press any key screen but before plymouth starts http://imgbin.org/index.php?page=image&id=9478
[12:25] <jbicha> I started seeing it in images I was building last night, and it's in the daily images today
[12:25] <xnox> jbicha: nope. seen the same thing. File a bug? but not sure which package though.....
[12:26] <cjwatson> knome: not got round to it
[12:26] <cjwatson> I'll sort it out today
[12:26] <knome> cjwatson, ok, cool. just checking :)
[12:26] <cjwatson> jbicha: That message is from the kernel
[12:26] <cjwatson> arch/x86/boot/video.c:332:              printf("Undefined video mode number: %x\n", mode);
[12:28] <cjwatson> knome: currently quite confused in branch hell, https://twitter.com/colmmacuait/status/245834286735974400
[12:28] <knome> cjwatson, strength and honour with that :)
[12:38] <knome> any release team member: can we have an ACK for a UIFe for bug 1043170 (we have our old wallpaper on plymouth, and we're uploading a new wallpaper without tiny dots in the bottom-right corner, since lightdm nor plymouth scales them well)
[12:38] <ubot2> Launchpad bug 1043170 in xubuntu-default-settings "Update Xubuntu wallpaper for Quantal" [High,Fix released] https://launchpad.net/bugs/1043170
[12:41] <knome> correction: plymouth has the new wallpaper too, only-ubiquity doesn't. so we need to change the wall on lightdm and plymouth to dotless, and replace the only-ubiquity with a new one.
[12:42] <knome> we'll take care of any screenshots that might have slipped in official docs or so, but i hardly think that has happened :)
[12:46] <cjwatson> knome: Ack.
[12:46] <knome> cjwatson, thanks
[12:52] <knome> ok, we need another UIFe to upload our installer slideshow; we've dropped gnumeric from our default seed and we need to change our "office" slide: bug 1049658
[12:52] <ubot2> Launchpad bug 1049658 in ubiquity-slideshow-ubuntu "[Xubuntu] Office slide needs to be updated" [Undecided,New] https://launchpad.net/bugs/1049658
[12:53] <Laney> knome: you should be subscribing the release team
[12:54] <Laney> pinging on IRC isn't the most efficient method
[12:54] <knome> subscribed
[12:54]  * Laney blinks at the amount of Unity exception requests
[12:55]  * knome is happy xubuntu doesn't have loads (this time)
[12:55] <knome> (maybe)
[12:55] <knome> :P
[12:55] <knome> well, that should be it really
[12:56] <knome> post-beta1 cleanup
[12:56] <knome> while we didn't even have beta1 ;)
[12:56] <Laney> do you have working images now?
[12:56] <knome> i'm told we have, but i haven't had time/been able to confirm that myself
[12:56] <Laney> cool
[12:57] <knome> yeah, there's still some hope...
[13:50] <skaet> SpamapS,  looks like precise-proposed just got flooded with translations.   Could you see if you can get it sane?
[14:13] <mvo> could someone from the release team please look at #1035207 ? its a FFe and its open for some days already and it would be great to get feedback on it
[14:13] <stgraber> bug 1035207
[14:13] <ubot2> Launchpad bug 1035207 in aptdaemon "[FFe] passwordless install of webapps (based on repo whitelist)" [High,In progress] https://launchpad.net/bugs/1035207
[14:18] <stgraber> mvo: when would this be uploaded?
[14:19] <mvo> stgraber: once I get a approval :)
[14:19] <stgraber> mvo: ok, and all of mdeslaur's concern are addressed by what you're planning on uploading?
[14:22] <mvo> stgraber: I think so,  I can double check with him
[14:22] <mvo> stgraber: or you can mandate that he approves in addition whatever is easier
[14:24] <stgraber> mvo: gave a conditional +1
[14:35] <mdeslaur> stgraber, mvo: I've commented in the bug, the aptdaemon part is fine, as it doesn't contain the whitelist file itself
[14:36] <mvo> mdeslaur: \o/
[14:36] <mvo> thanks
[14:36] <mdeslaur> np
[15:29] <mterry> Hello!  John Lea requested a few UI changes to the greeter for 12.10.  It's 4 changes, you can see them linked from bug 1049231.  I've got a test package in a PPA (linked from that bug too).
[15:29] <ubot2> Launchpad bug 1049231 in unity-greeter "[UIFe] The gap between the user name and password entry is too large in the greeter" [Undecided,New] https://launchpad.net/bugs/1049231
[15:30] <ogra_> i guess by that time you should talk to the doc team too ... screenshots etc
[15:32] <mterry> ogra_, shouldn't I get UIFe approval first, before bothering them?
[15:32] <ogra_> well, doesnt UIFe involve talking to them ?
[15:32]  * ogra_ isnt sure
[15:32] <mterry> jbicha, ^ any comment on the above 4 greeter changes linked to that bug
[15:32] <Laney> yes, you should mail them first
[15:33] <mterry> Laney, ah first...  I thought after
[15:33] <dobey> infinity: have attached new package files to https://bugs.launchpad.net/ubuntu/+bug/1047606
[15:33] <ubot2> Launchpad bug 1047606 in Ubuntu Quantal "[needs-packaging] [FFe] [UIFe] ubuntuone-client-data" [Wishlist,New]
[15:33]  * ogra_ thought at the same time :)
[15:33] <Laney> https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions
[15:33]  * Laney eyes the number of unity changes
[15:34] <Laney> s/changes/exceptions/
[15:34] <infinity> dobey: Just go ahead and upgrade it, I can review it from the NEW queue.
[15:34] <infinity> dobey: s/upgrade/upload/
[15:34]  * infinity needs coffee.
[15:34]  * TheLordOfTime gives infinity coffee
[15:34] <TheLordOfTime> :p
[15:34] <dobey> infinity: i am not motu, so i can't upload it?
[15:35] <infinity> dobey: Oh, derp.  Okay, I'll have a look at it and sponsor it if it looks sane.
[15:35] <dobey> infinity: great, thanks
[15:47] <mterry> Laney, ogra_: OK, ubuntu-doc posting linked to in main UIFe bug
[15:48] <ogra_> :)
[17:14] <infinity> stgraber: queuebot appears to be having a hissy fit parsing the queue again, while I'm accepting a mess of things.
[17:14] <infinity> stgraber: (I'm accepting langpacks, it's flipping out about.. Everything else)
[17:15] <infinity> I got all excited that maybe someone had reviewed and accepted eglibc. :P
[17:16] <stgraber> infinity: killed for now
[17:17] <stgraber> infinity: that's really weird, I'm not getting any traceback on queubot's side, so it looks like it's just getting partial data from Launchpad when the queue changes while it contains a lot of entry
[17:18] <infinity> stgraber: Yeah, I wasn't implying that it was necessarily queuebot's "fault", it may well be the API giving you lousy results.
[17:23] <infinity> stgraber: All done, you can let it back in.
[17:34] <skaet> infinity,  re: we'll need to double check with dpm-afk on those translations before they are moved from precise-proposed to -updates.   From discussions I had with him earlier today,  he was surprised that they were there,  and was investigating.
[17:35] <skaet> SpamapS ^
[17:35] <infinity> skaet: We require some sort of manual verification before they move to -updates anyway, so this isn't new.
[17:36] <infinity> skaet: But if the whole upload was a mistake in general, we can also just remove them from -proposed.
[17:36] <skaet> infinity,  yup.   just wanted it visible in the channel that there was some questions about them.
[17:36] <SpamapS> ACK
[17:36] <skaet> :)
[18:15] <plars> Daviey: ping
[18:16] <Daviey> plars: HELLO!
[18:16] <plars> Daviey: ubuntu-server doesn't seem to be installable with 128M currently, lots of ooms, trying 256M now which seems to get further, but hitting unmet deps when trying to install the kernel headers so it doesn't finish
[18:16] <Daviey> that is less than cool.
[18:17] <Daviey> ah
[18:17] <plars> I can do some bisection to find a number in the middle if you think it's worth it
[18:17] <Daviey> I suspect 12.10 has higher requirements than 12.04 had, due to the squashfs changes.. but I haven't tested.
[18:18] <Daviey> plars: Well, currently I have no data on what to recommend for 12.10.. so that would be helpful.
[18:19] <Daviey> plars: what image failed to install due to headers?
[18:19] <plars> Daviey: 20120912
[18:19] <plars> current
[18:19] <Daviey> damn
[18:20] <plars> Daviey: with 128 it seems to get stuck around running partman
[18:20] <Daviey> I'm concerned that it workjed in Jenkins
[18:20] <Daviey> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-server-amd64_default/
[18:20] <Daviey> Oh!  This only happens with lowmem?
[18:21] <plars> Daviey: yes, was about to say... I was running with 256 when I hit that
[18:21] <plars> but there was no oom
[18:21] <Daviey> plars: can you automate testing different values?
[18:22] <Daviey> or rather, script it?  It would be good to add to Jenkins long term, when we have a settled figure
[18:22] <plars> Daviey: not easily at the moment, mostly due to my own unfamiliarity with the automation at the moment, but it's not hard to try
[18:22] <Daviey> plars: Have you toyed with UTAH?
[18:22] <plars> Daviey: what I'm working on at the moment is a test for the minimum supported system requirement
[18:23] <plars> Daviey: so that's the end goal, but my branch of ubuntu-server-iso-testing with a couple of changes in place to do that with 128m seemed to be getting stuck so I tried it locally
[18:23] <xnox> plars: Daviey: did you set lowmem bootime option to the debian-installer?
[18:23] <plars> Daviey: I thought what you were requesting was an ad-hoc script to go test with 1M increments or something
[18:23] <xnox> ... although 128MB doesn't sound that lowmem to me...
[18:23] <plars> xnox: I'm just booting with kvm -m ### at the moment
[18:24] <Daviey> plars: there is a kernel command line option called lowmem
[18:25] <plars> hmm.. hadn't heard of it, I found https://help.ubuntu.com/community/Installation/LowMemorySystems but oddly it doesn't seem to mention it
[18:25] <Daviey> I don't think it will change anything TBH
[18:26] <Daviey> jamespage: do you have thoughts on using UTAH for automated min memory spec testing?
[18:26]  * xnox has no clue what it actually does. I was just poking installer boot options once I found it
[18:27] <plars> Daviey: I'll be looking into that too, but I haven't really had a chance to look into utah much yet, and we aren't converting to it in the lab until after quantal is done
[18:28] <jamespage> Daviey: possible definately
[18:28] <jamespage> if it can be preseeded then I think we can use a minimal KVM configuration to test it
[18:28] <plars> Daviey: at the moment, my bigger concern is making sure that we have 1. correct values for minimum system requirements, and 2. that we test them with current infrastructure, then that we get it working with utah so that we are ready for next cycle
[18:28] <Daviey> jamespage: certainly indefinitely ?
[18:28] <plars> that's exactly what I'm doing right now with ubuntu-server-iso-testing
[18:29] <jamespage> my only concern would be that squeezing the utah stuff into a minimum spec KVM might be to much
[18:29]  * Daviey has NFI ;)
[18:30] <plars> Daviey: TBH, that's a concern for tomorrow, for today I'd rather stick to - should 128 really be the minimum? or should it be extended?
[18:30] <Daviey> plars: Yah
[18:32] <plars> Daviey: and skaet sent me to ask you on that
[18:34]  * skaet nods
[18:34] <TheLordOfTime> where do i ask questions about the SRU docs?
[18:35] <Daviey> TheLordOfTime: here would often be ok, depending on traffic
[18:35] <Daviey> otherwise #ubuntu-deverl
[18:35] <Daviey> err, -devel
[18:35] <Daviey> plars: I think 192MB would be a more reasonable minimal TBH
[18:36] <TheLordOfTime> https://wiki.ubuntu.com/StableReleaseUpdates#sun-java.2A  <-- isn't this incorrect?  i thought sun-java* were removed after 11.04 (it says the binaries are still shipped in multiverse)
[18:36] <plars> Daviey: that was going to be the next thing I would try :)
[18:37] <Daviey> plars: In Lucid timeframe, we decided to switch the cloud images smallest option from 128 to 192, due to issues (bug 544292).. But that was for a running machine, rather than the installer - which i'd expect to be more intensive TBH
[18:37] <ubot2> Launchpad bug 544292 in eucalyptus "Increase m1.small memory to 192 MB" [Wishlist,Fix released] https://launchpad.net/bugs/544292
[18:37] <plars> Daviey: unless you said "no, 128 is it, file a bug if it ooms with 128M"
[18:37] <plars> Daviey: yeah, it couldn't be serving *too* much if di was the most intense thing it ever ran
[18:38] <Daviey> TheLordOfTime: i believe you to be correct.
[18:39] <Daviey> plars: well, from my experience, a high proportion of servers sit near idel.. The 'expensive' time is install & boot, as it's actually being hammered.
[18:39] <TheLordOfTime> Daviey:  iirc my 11.04, that was the last version to ship a sun java 6 version, but i may be wrong on that.  it was somewhere around there that occurred
[18:40] <Daviey> jamespage / doko: You are more familiar with this i suspect.. ( TheLordOfTime's issue )
[18:40] <TheLordOfTime> its more of a documentation issue, rather than package issues, but hey, i notice random things like this ;)
[18:40] <micahg> 8.04 is the only repo left with java in multiverse
[18:41] <TheLordOfTime> micahg:  then the documentation on SRU special cases needs changing, it says 9.04 and later have binaries in multiverse
[18:41] <micahg> the wiki is correct though for WIW
[18:41] <TheLordOfTime> it is?
[18:41] <micahg> 8.04 doesn't have desktop support any more thugh
[18:41] <micahg> *though
[18:42] <TheLordOfTime> so when 8.04 goes EOL, then the docs will probably need revising, I assume.
[18:42] <micahg> yeah
[18:42] <micahg> TheLordOfTime: it says before 9.04 had them in multiverse
[18:43] <TheLordOfTime> micahg:  ah, i see, i misread.
[18:43] <micahg> well, technically they were in multiverse until 9.10
[18:43] <micahg> what it says is the ones in multiverse before 9.04 were the only ones
[18:44] <TheLordOfTime> I see, I misread.
[18:44] <TheLordOfTime> thanks for clearing that one up :P
[18:45] <plars> Daviey: oh, I see the reason for the headers failing... it's not an unmet dep... looking further up, it ran out of space with 1G, though to be fair let it do a swap partition.  Let me redo that
[18:45] <plars> no swap on this one, and I'll make sure that goes in the preseed
[18:45] <TheLordOfTime> unrelated, but what's the general turnaround time for getting an SRU from -proposed to -updates when verification-done is tagged on the bug(s) that'd be fixed by the SRU?
[18:46] <micahg> TheLordOfTime: after ~7 days of being in -proposed
[18:47] <Daviey> TheLordOfTime: is there a particular one annoying you?
[18:47] <TheLordOfTime> Daviey:  not annoying me per se, might be annoying some people, but its not high-priority
[18:47] <TheLordOfTime> so no need to poke it up, was curious about the general turnaround time is all
[18:47] <TheLordOfTime> :)
[18:48] <SpamapS> hrm.. what happened to grub2 1.99-21ubuntu3.2 ?
[18:48] <SpamapS> Just accepted 3.3 but now noticing 3.2 is not in -updates or -proposed
[18:49] <micahg> Deleted in precise-proposed on 2012-06-06 (Reason: wrong solution to #1009294)
[18:49] <SpamapS> Ok, so the next upload should be based on 3.1 not 3.2?
[18:50]  * SpamapS notes that UDD should be banished from -updates and -proposed as its likely what caused this
[18:50] <micahg> well, I would think reverting 3.2 and then adding on top
[18:50] <SpamapS> I hit accept before thinking about what was between 3.1 and 3.3 ... now I'm thinking that should be rejected..
[18:51]  * micahg defers to SRU people like infinity
[18:51] <SpamapS> I think I need to also delete this one from -proposed, and ask the users to base off -updates and fix lp:ubuntu/precise-proposed/grub2
[18:52] <micahg> I wouldn't manually "fix" the UDD branch
[18:52] <Daviey> I don't think it's a big deal, based on 3.1 OR 3.2+reversed-patch->&changelog explaining reversal.. Really either way comes down to a changelog message.  Providing it doesn't include something that clearly sucked.
[18:52] <SpamapS> Daviey: 3.3 includes 3.2
[18:52]  * micahg would think you now need a 3.4 which includes the reversion of 3.2 and -v on what's in updates
[18:52] <SpamapS> actually I like that solution better
[18:53] <SpamapS> "fail forward" :)
[18:53] <Daviey> SpamapS: Have you accepted the binaries or just the sourcE?
[18:53] <Daviey> uhh
[18:53] <SpamapS> Daviey: there's no accepting of binaries AFAIK .. unless you mean moving to -updates. I just accepted the source into -proposed.
[18:54] <Daviey> yeah, iw as being daft. Sorry.
[18:55] <SpamapS> I'll just upload a reverted 3.2, 3.4, myself
[18:55] <micahg> yeah, if you hurry, it'll supersede the amd64 and powerpc builds
[18:56] <micahg> hurry ~= 15-20 min :)
[19:00] <dobey> infinity: i guess you didn't find anything to complain about with ubutnuone-client-data? :)
[19:01] <infinity> dobey: No, it's just been a busy morning.  I'll get to complaining (or uploading) later.
[19:05] <TheLordOfTime> infinity:  mind a privmsg?
[19:06] <infinity> TheLordOfTime: No need to ask.
[19:26] <balloons> njin found this bug -- not sure how many images are affected by it just yet. But the daily images just flat out are not booting
[19:26] <balloons> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1050006
[19:26] <ubot2> Launchpad bug 1050006 in casper "Undefined video mode number: 0" [Undecided,Confirmed]
[19:33] <jbicha> balloons: yeah, I reported bug 1049650 earlier today
[19:33] <ubot2> Launchpad bug 1049650 in linux "Regression: "Undefined video mode" with 3.5.0-14.16" [Medium,Incomplete] https://launchpad.net/bugs/1049650
[19:33] <jbicha> after the 30 second wait, the image did seem to boot for me
[19:34] <kanliot> If there is no documentation for mode 0, how do you know it is a bug?
[19:38] <balloons> jbicha, ok, let me see
[19:40] <balloons> ahh.. new background ;-)
[19:51] <SpamapS> would appreciate it if somebody else on the SRU/release team sanity checked my grub2 upload to precise-proposed
[19:56] <infinity> SpamapS: Wait, that's a revert of a revert?
[19:56] <infinity> SpamapS: My head hurts.
[19:57] <TheLordOfTime> heh
[20:00] <infinity> Or... A revert of a revert of a revert.. I think.
[20:02] <SpamapS> infinity: mine too
[20:03] <SpamapS> http://www.youtube.com/watch?v=VW27kyh7PVM
[20:03] <infinity> SpamapS: Diffing from 3.1 to 3.4 makes it obviously correct, accepted.
[20:03] <SpamapS> infinity: ty
[22:50] <cjwatson> Daviey,plars: the installer includes a "lowmem" package which has experimentally-determined values for memory limits at various stages; tweaking those will change the behaviour
[22:50] <cjwatson> so you shouldn't assume that current memory behaviour in d-i is immutable
[22:50] <cjwatson> There's specific advice in lowmem/README on how to update those levels
[22:50] <cjwatson> And the hacks that are currently performed in lowmem situations
[22:52] <cjwatson> I would also say that a failure at 128M represents a significant change only over about two years well in excess of my expectations of natural drift, so deserves investigation in its own right
[23:06] <Daviey> cjwatson: wait, it's in limits of your expectations of natural expansion ?
[23:08] <infinity> Daviey: That's not how I'd read "well in excess of my expectations of natural drift".
[23:11] <cjwatson> Daviey: I am surprised that d-i fails at 128M, and think that's worth investigating in itself.
[23:11] <Daviey> ok, thanks. wanted to check.
[23:12] <cjwatson> I don't think squashfs is necessarily all that directly related, since the high-water-mark for d-i memory use is supposed to be immediately before swap is enabled.
[23:12] <cjwatson> Which is before we mount the squashfs and start trying to copy files off it.
[23:13] <Daviey> well, i'll see what plars results are.. but also might try to gauge the entire process.
[23:14] <cjwatson> As I say, the README file in the lowmem source package has specific advice on measuring this, which is likely to be better than what you or I or plars would come up with off the top of our heads.
[23:14] <cjwatson> Because it's advising on the particular points that affect the behavioural changes in lowmem.
[23:16] <plars> Daviey, cjwatson: from my initial 10 sec skim of a checkout of lowmem, the readme seems to suggest that low memory conditions should be detected automatically, so thee shouldn't be anything for me to adjust for enabling this right?
[23:16] <plars> I'm booting in a VM with 128M
[23:16] <plars> Daviey: oh, also I did some experiments in jenkins earlier and even with 196M, I was getting lots of OOMs during installation, with 256M too
[23:17] <plars> need to look into that a bit more still, will try to do that later this evening if I have time
[23:18] <cjwatson> plars: Indeed, normally.  The point of the lowmem= option is to find out easily whether the additional optimisations carried out by lowmem would help in a particular case.
[23:19] <Daviey> plars: is this a heavily loaded host, where the VM is running ?
[23:19] <plars> Daviey: not that I'm aware of, but I would have to check with retoaded to be sure
[23:19] <Daviey> plars: would be interesting to see that
[23:20] <Daviey> plars: do you know what machine it's running on?
[23:20] <cjwatson> lowmem=1 and lowmem=2 enable progressively more low-memory optimisations.
[23:21] <cjwatson> (These are also automatically enabled below certain hardcoded thresholds.)
[23:21] <plars> Daviey: wazn
[23:22] <plars> Daviey: my job was the only thing running at the time as far as jenkins is concerned, but I can't speak to what else might be going on with that system
[23:23]  * plars has to go afk for a bit, will try to look into it a bit more later


[12:32] <topyli> is it out yet?
[12:32] <topyli> :)
[12:41] <kklimonda> mm.. dzień dobry to all.. good to be back ;)
[12:42] <yofel> hey kklimonda
[12:43]  * yofel just sent a ident.ca message to bugabundo, so he should be here soon too
[12:43] <kklimonda> so, who, beside bugabundo, is already running maverick? ;)
[12:44] <yofel> haha, not yet, I want to repartition my HD here so I have lucid as a backup this time, lucid pre-alpha was a mess
[12:46] <kklimonda> heh, I do an upgrade around alpha2 anyway - and I'm considering running lucid at least until beta release this time
[13:25] <Ian_Corne> Aha :)
[13:28] <Ian_Corne> Anyone know the time when I'll be able to update via update-manager -d?
[13:28] <yofel> Ian_Corne: alpha1
[13:29] <Ian_Corne> Gah
[13:29] <Ian_Corne> The dillemas
[13:37] <hifi> kklimonda: I do
[15:49] <BluesKaj> howdy
[16:03] <Timo_> howdy
[19:12] <BUGabundo> MAMA I'M BACK!!
[19:13] <Ian_Corne> Welcome back!
[19:13] <Ian_Corne> Got any machine on maverick yet?
[19:17] <BUGabundo> mine
[19:17] <BUGabundo> since day 1
[19:17] <BUGabundo> :)
[19:17] <BUGabundo> Ian_Corne: do you really think I would wait?
[19:18] <charlie-tca> BUGabundo: You made it!
[19:18] <BUGabundo> I did charlie-tca :)
[19:18] <BUGabundo> thanks to yofel for the heads up :)
[19:19] <yofel> hey
[19:19] <charlie-tca> I saw the changes message in announcements
[19:20] <BUGabundo> which changes?
[19:20] <Ian_Corne> I'm not going to upgrade till monday :(
[19:20] <Ian_Corne> limited bandwith at home
[19:20] <charlie-tca> They have already opened the maverick changes mailing list
[19:21] <charlie-tca> https://lists.ubuntu.com/mailman/listinfo/maverick-changes
[19:21] <BUGabundo> ahh
[19:21] <BUGabundo> I stop tracking that in 7.04
[19:21] <charlie-tca> heh
[19:22] <charlie-tca> apparently, I don't get enough email yet
[19:22] <BUGabundo> I don't read any more ML mail
[19:23] <BUGabundo> and even bug mail... only once a week
[19:23] <charlie-tca> I couldn't read it all just once a week. The backlog would be too high
[19:24] <BUGabundo>   deja-dup: Depends: gconf2 (>= 2.28.1-2) but 2.28.1-0ubuntu1 is installed.
[19:24] <BUGabundo> there we go... deps conflits: start.now();
[19:24] <yofel> I look at mails every day, but sort the ML mails in different folders
[19:24] <BUGabundo> I have diff emails accounts :)
[19:24] <yofel> not scalable if anything gets into the inbox...
[19:25] <BUGabundo> each ML goes to each own folder :)
[19:39] <knittl> hi. when can i dist-upgrade? :D
[19:40] <BUGabundo> you can already
[19:40] <BUGabundo> just need to sed sources
[19:40] <alex_mayorga> knittl: june 3rd it seems
[19:40] <knittl> hiiii BUGabundo :)
[19:40] <BUGabundo> no stuff for UM at this time
[19:40] <knittl> um?
[19:40] <BUGabundo> that would be around alpha1
[19:40] <alex_mayorga> BUGabundo: what is there worthy in Meerkat as of now?
[19:41] <knittl> the joy of testing
[19:41] <BUGabundo> what he said :)
[19:41] <knittl> BUGabundo: so, sed -i 's/lucid/maverick/g'? ;)
[19:41] <BUGabundo> NO
[19:41] <BUGabundo> attention to PPAs
[19:41] <BUGabundo> and I would keep security repos for lucid, for now
[19:42] <knittl> i do not have any ppas
[19:42] <BUGabundo> they should be build faster  then regular maverick
[19:42] <BUGabundo> you don't have ppa???????
[19:42] <knittl> how do you mean security repo?
[19:42] <knittl> no, i am happy with the default repos
[19:42] <yofel> lucid-security
[19:42] <yofel> and do you mean 'own ppa' or 'use ppa' ?
[19:43] <knittl> i don't use ppas
[19:43] <yofel> wow...
[19:44] <knittl> hm what's the big fuss about not using ppas? oO
[19:44] <Ian_Corne> It provides certain unavailble or more up to date packages :)
[19:44] <yofel> I'm using 7 right now, my own ones not counted
[19:44] <knittl> but nobody forces me to use 'em
[19:44] <Ian_Corne> obviously :p
[19:45] <knittl> so i can replace lucid with maverick and should be good to go to do a dist-upgrade?
[19:45]  * jpds doesn't use PPAs either.
[19:46] <yofel> knittl: pretty much
[19:46] <yofel> I had ~70 packaged that were updated when I upgraded an hour ago :D
[19:46] <BUGabundo> yofel: that what I said : wow :)
[19:46] <yofel> heh
[19:46] <BUGabundo> knittl: aptitude safe-upgrade; aptitude full-upgrade
[19:46] <alex_mayorga> have the goals for meerkat been set?
[19:47]  * BUGabundo goes count ppas
[19:47] <jpds> alex_mayorga: No, we're doing that next week.
[19:47] <knittl> 62 packages upgraded, 1 new :)
[19:47] <BUGabundo> $ grep ppa /etc/apt/sources.list | wc -l
[19:47] <BUGabundo> 20
[19:47] <alex_mayorga> jpds: got a link on how to get involved?
[19:47] <alex_mayorga> jpds: or maybe just watch?
[19:47] <knittl> yay, updating
[19:47] <BUGabundo> repos: $ cat /etc/apt/sources.list | wc -l 45
[19:48] <jpds> alex_mayorga: https://wiki.ubuntu.com/UDS-M/RemoteParticipation
[19:48] <alex_mayorga> jpds: thanks!
[19:48] <BUGabundo_DrWho> wooo wooo Darlek time :)
[19:56] <patdk-wk> hehe
[19:57] <patdk-wk> meerkat manor?
[19:58] <knittl> yay, upgraded :>
[20:22] <kklimonda> BUGabundo_DrWho: Daleks? you are behind the schedule! it's time for Venice
[20:22] <jpds> That was 2 hours ago.
[20:23] <BUGabundo_DrWho> I know
[20:23] <BUGabundo_DrWho> some how I never download them :)
[20:23] <BUGabundo_DrWho> so back on S05E03
[20:55] <MaximLevitsky> I am worried about gnome-shell
[20:56] <MaximLevitsky> How much will it be forced on us?
[20:57] <yofel> isn't is supposed to be the default in 11.04? (not sure about maverick)
[20:57] <yofel> s/is/it/
[20:58] <MaximLevitsky> yofel: I can live with 'default'
[20:58] <MaximLevitsky> but compiz, will it still be supported?
[20:58] <BUGabundo_DrWho> yofel: you are in an hurry
[20:59] <BUGabundo_DrWho> [OT] in case anyone wants to give me an early gift... I want one of this http://micgadget.com/3381/ipad-knockoff-upgraded-with-android-2-1-and-larger-display/
[20:59] <MaximLevitsky> bear in mind that compiz does a release soon, and from that point will get many new featurws
[20:59] <yofel> not much, but I am interested in how gnome3 will look like, can't get myself to like gnome-shell 2.28 though :/
[21:04] <kklimonda> MaximLevitsky: it's getting features of bling? ;)
[21:04] <kklimonda> or*
[21:04] <MaximLevitsky> kklimonda: probably will get MPX support
[21:05] <MaximLevitsky> kklimonda: as you know compiz always got 50:50 of that
[21:12] <ubuntujenkins> MaximLevitsky: I read that gnomesheel will not be default in mavrick but will be installable as a package
[21:12] <ubuntujenkins> *shell
[21:12] <MaximLevitsky> ubuntujenkins: this is great
[21:13] <ubuntujenkins> MaximLevitsky: http://www.omgubuntu.co.uk/2010/05/mark-shuttleworth-no-gnome-shell-in.html thats where i read it
[21:18] <yofel> it already is installable in lucid, not quite up-to-date though
[21:22] <bruce89> hello BUGabundo_DrWho
[21:22] <BUGabundo_DrWho> hey bruce89
[21:22] <BUGabundo_DrWho> welcome back dear friend
[21:23] <BUGabundo_DrWho> even if you are still on "the other side"
[21:23] <bruce89> heh, I'll behave mysel
[21:23] <BUGabundo_DrWho> know that many of us , share the same point of view as you do
[21:23] <BUGabundo_DrWho> just not the _balls_ to change :)
[21:23] <bruce89> heh
[21:27] <patdk-wk> other side?
[21:27] <bruce89> the F word
[21:27] <BUGabundo_DrWho> he abandoned *buntu
[21:27] <BUGabundo_DrWho> cause he didn't agree with many of canonical policies
[21:27] <patdk-wk> ah
[21:27] <bruce89> don't worry, I'm here to just be nice
[21:28] <patdk-wk> I don't agree with many policies
[21:28] <patdk-wk> and I use the hell out of rhel5
[21:28] <patdk-wk> but don't like it
[21:28] <patdk-wk> my one attempt at f* was a big failure
[21:28] <patdk-wk> probably due to my slackware background
[21:33] <BUGabundo_DrWho> well I still like ubuntu
[21:33] <BUGabundo_DrWho> and admit some of this changes will be good in the mid term
[21:33] <BUGabundo_DrWho> but it will run over many users
[21:33] <BUGabundo_DrWho> and they either endur or move..
[21:34] <BUGabundo_DrWho> .... like our bud bruce89 did
[21:34]  * yofel moved next door to Kubuntu and is happy :P
[21:34] <BUGabundo_DrWho> ahah
[21:34] <charlie-tca> I agree. Of course, I use Xubuntu instead, which doesn't really have those changes.
[21:35] <ddecator> whoa, it's open again
[21:35]  * patdk-wk doesn't like kde at all
[21:35] <bruce89> I was finding myself being more GNOMEy anyway
[21:36] <yofel> kde and gnome go pretty much in the exact opposite direction when it comes to philosophy, depends on fits you better
[21:37] <yofel> *what fits
[21:37] <yofel> hey ddecator, welcome ;)
[21:37] <ddecator> thanks yofel =)
[21:37]  * patdk-wk notes he has a dirty mind
[21:38] <ddecator> won't be on maverick until a3, but i'll chill in here and see what happens
[21:38] <bruce89> I very much like gnome-shell
[21:39]  * BUGabundo_DrWho hugs ddecator till he run out of air
[21:39]  * ddecator passes out
[21:40] <BUGabundo_DrWho> ddecator: don't! join us NOW
[21:40] <ddecator> BUGabundo_DrWho: i would, but i kinda need my comp to do homework, haha. i'll use testdrive here and there to test things out before a3
[21:41] <BUGabundo_DrWho> do it from grub2 and daily isos
[21:41] <BUGabundo_DrWho> that's what I do
[21:42] <ddecator> do it from grub2?
[21:42]  * patdk-wk is alittle paranoid
[21:42] <patdk-wk> I can't remember if it was the intrepid or karmic 64bit install cd
[21:42] <MaximLevitsky> The thing that really stinks about gnome-shell is that it forces windows manager on us
[21:43] <patdk-wk> but one of them had a bad wifi driver for my intel card, that kept corrupting ext3
[21:43] <patdk-wk> I disabled the wifi card the bios and all was good
[21:44] <BUGabundo_DrWho> ddecator: I have it on my blog  p.bugabundo.net
[21:45] <ddecator> BUGabundo_DrWho: looks like you have a little bit of everything on there, haha
[21:45] <BUGabundo_DrWho> tag grub2
[21:45] <ddecator> ...i just noticed that your nick says DrWho, and you are amazing for that
[21:46] <BUGabundo_DrWho> lol
[21:46] <BUGabundo_DrWho> your torrent is downloading
[21:46] <BUGabundo_DrWho> 34.78 MB / 49.01 MB cached - 70.9%
[21:46] <BUGabundo_DrWho> 196 KB/s - 1 mins left
[21:46] <BUGabundo_DrWho> oopss
[21:46] <BUGabundo_DrWho> wrong tab
[21:46] <BUGabundo_DrWho> that's legal, btw :) cyanogenmod rom for my android
[21:47] <ddecator> haha
[21:47] <ddecator> BUGabundo_DrWho: thanks, i'll have to check that out once i get out of school and have the time to experiment more with my comp
[22:38] <bruce89> the magic of British democracy
[22:46] <BUGabundo_NCIS> yofel: wrong account :(
[22:47] <BUGabundo_NCIS> send "unsub bugabundo" a few times till you remove all
[22:47] <yofel> I'm getting confused, identi.ca unsubcribed me from all...
[22:47] <BUGabundo_NCIS> and then resub with "sub<EMAIL_ADDRESS>[22:48] <BUGabundo_NCIS> yofel: you mean you lost everyone you were subbed to?
[22:49] <yofel> not everyone, I just noticed that I didn't get any messages from you anymore after I left the 'ubuntu' and 'linux' groups a few days ago, now I saw that I got unsubscribed from you too somehow
[22:49] <yofel> and didn't quite know which one to subscribe again ^^
[22:49] <yofel> right acc. now?
[22:50] <BUGabundo_NCIS> I got it
[22:50] <BUGabundo_NCIS> testing
[22:51] <yofel> I meant I didn't recieve any of your usual posts, @ still worked fine obviously
[22:52] <BUGabundo_NCIS> got it yofel?
[22:52] <yofel> I did, thanks :)
[22:52] <BUGabundo_NCIS> I bet your timeline got quiet.... with me on it :)
[22:52] <BUGabundo_NCIS> you *only* lost 20~40 notices per day :)
[22:53] <yofel> well, I left ubuntu and linux as it was too much, but now it got too quiet ^^
[22:54] <BUGabundo_NCIS> I noticed that when I moved to OMB, now OStatus
[22:54] <BUGabundo_NCIS> and could not sub to groups
[22:58] <sebsebseb> Hi
[22:58] <bruce89> hello
[23:00] <BUGabundo_NCIS> hey hey sebsebseb
[23:00] <sebsebseb> yeah hi BUGabundo_NCIS
[23:02] <bruce89> one way to change that sebsebseb
[23:03] <sebsebseb> bruce89: you made it sound like something interesting was going on in here, but nope
[23:03] <bruce89> there is, I'm here
[23:04] <BUGabundo_NCIS> hahah
[23:04]  * BUGabundo_NCIS smacks bruce89 in the head
[23:05] <bruce89> fair enough
[23:07] <bruce89> hello malnilion
[23:08] <malnilion> Hello.
[23:08] <bruce89> or mattgirv even, I'm going to have to shoot myself now
[23:08] <malnilion> lol
[23:08] <mattgirv> bruce89: Hoho, hello :)
[23:08] <bruce89> it'll be bloody tories in No10 next
[23:08] <bruce89> oh wait
[23:08] <mattgirv> bruce89: They'll arrange the shooting for you, no doubt.
[23:09] <sebsebseb> this channel gets logged by the way guys
[23:09] <mattgirv> sebsebseb: Sounds nice.
[23:09] <bruce89> hello insomniacs!
[23:15] <bruce89> incidentally, I think the Tories are lovely people who are going to be very good for this country
[23:15] <bruce89> when they get forced out in 2 months time...
[23:16] <mattgirv> bruce89: I heard David Cameron uses Ubuntu?
[23:16] <sebsebseb> mattgirv: I doubt it
[23:17] <bruce89> don't get me started
[23:25] <patdk-wk> why do people care about david cameron?
[23:25] <patdk-wk> gates uses windows, so I should too!
[23:25] <mattgirv> Who said anyone cared?
[23:27] <bruce89> does he really use it?
[23:28] <mattgirv> No
[23:28] <bruce89> aw
[23:30] <jpds> !politics
[23:32] <bruce89> apparently John Beattie uses Ubuntu
[23:37] <bruce89> if John reads that, sorry
[23:39] <acicula> is there sort of a test framework/sequence to go through to test new ubuntu? have a kvm or virtualbox instance to test the new release in
[23:40] <jpds> !info testdrive
[23:40] <acicula> i know of testdrive, thats just to facilitate running it


[06:38] <mborzecki> morning
[06:51] <mvo> good morning mborzecki
[06:56] <mborzecki> mvo: hey
[06:57] <mborzecki> mvo: heh: https://forum.snapcraft.io/t/firefox-83-0-snap-was-broken-fixed-square-fonts/21248
[07:12] <jamesh> hi mvo, mborzecki
[07:12] <mborzecki> jamesh: hey
[07:16] <jamesh> I did a little experiment on the weekend to see how much of go-check I could delete while still retaining the features I use: https://github.com/go-check/check/pull/122 -- it's functional (apart from its own tests), and opens the door to parallel testing
[07:16] <mup> PR go-check/check#122: check: replace test runner logic with Go's stdlib subtest support <Created by jhenstridge> <https://github.com/go-check/check/pull/122>
[07:16] <jamesh> it turns each go-check test into a stdlib testing sub-test
[07:25] <zyga> good morning
[07:28] <zyga> mborzecki, heh more selinux denials I see
[07:28] <zyga> type=PROCTITLE msg=audit(11/23/20 00:49:39.509:26526) : proctitle=/usr/libexec/snapd/snap-update-ns snap-store
[07:28] <zyga> type=SYSCALL msg=audit(11/23/20 00:49:39.509:26526) : arch=x86_64 syscall=unlinkat success=yes exit=0 a0=0xffffffffffffff9c a1=0xc0001a8250 a2=0x200 a3=0xc0001a8250 items=0 ppid=3053 pid=6546 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=snap-update-ns exe=/usr/libexec/snapd/snap-update-ns subj=system_u:system_r:snappy_mount_t:s0 key=(null)
[07:28] <zyga> type=AVC msg=audit(11/23/20 00:49:39.509:26526) : avc:  denied  { rmdir } for  pid=6546 comm=snap-update-ns name=.X11-unix dev="sda2" ino=34699367 scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=1
[07:28] <zyga> are those from the x11 fixes?
[07:29] <zyga> mvo did merging the internal snap-device-helper regress anything, e.g.: google:ubuntu-core-18-64:tests/main/security-dev-input-event-denied
[07:31] <mborzecki> zyga: rmdir .x11-unix?
[07:32] <mborzecki> jamesh: nice, i like the fact that with the change the pattern where we loop over a list of test cases could use t.Run() again, no more commenting out test cases to run a specific one
[07:33] <zyga> mborzecki, I didn't look deeper, just reviewed logs of failed tests
[07:33] <zyga> hey jamesh :-)
[07:33] <zyga> I read your post about the go testing
[07:33] <mborzecki> zyga: which PR is that?
[07:34] <zyga> https://github.com/snapcore/snapd/pull/9546
[07:34] <mup> PR #9546: overlord: add inert export manager <Created by zyga> <https://github.com/snapcore/snapd/pull/9546>
[07:34] <zyga> I sent some patches there yesterday
[07:35] <mborzecki> hm i see that on centos 7 only
[07:41] <jamesh> hi zyga
[07:58] <mvo> zyga: oh, nice, thanks for updating that PR!
[07:59] <mvo> mborzecki: noooo, fonts again :(
[07:59] <zyga> hey mvo :-)
[08:03] <mborzecki> pstolowski: hey
[08:04] <pstolowski> morning
[08:04] <zyga> hey pawel
[08:04] <zyga> updated fusion over weekend
[08:22] <mvo> good morning pstolowski
[08:30] <pstolowski> o/
[08:33] <zyga> good morning pedronis
[08:33] <zyga> pedronis, I pushed a few patches to the inert export manager PR
[08:39] <pstolowski> mvo: https://forum.snapcraft.io/t/important-internal-change-to-snap-downloads-in-edge-future-snapd-2-49/21255
[08:40] <mvo> pstolowski: yay, nice!
[08:51] <mvo> jamesh: hey, not sure if you have seen it, I added some comments on 8943 and approved it, let me know if you want to address anything (just nitpicks) and if you want to do it in the PR or rather as a followup, either way is fine. if followup I can merge the PR now
[08:52] <jamesh> mvo: yeah.  I'm addressing those now.
[08:52] <jamesh> mvo: thanks
[08:53] <mvo> jamesh: \o/ thank you!
[09:12] <mborzecki> i've landed #9640, let me know of tests/nested/manual/core20-save fails in any of the PRs
[09:12] <mup> PR #9640: tests/nested/manual/core20-save: verify handling of ubuntu-save with different system variants  <Run nested> <Squash-merge> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9640>
[09:15] <mborzecki> hmm cannot perform operation: mount --bind /var/lib/snapd/snap/core18/current/etc/apparmor /tmp/snap.rootfs_08zCTp/etc/apparmor: Permission denied
[09:15] <mborzecki> that's when trying the updated 2.48 package on arch
[09:16] <mborzecki> [lis23 10:16] audit: type=1400 audit(1606122967.226:703): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/proc/77278/attr/apparmor/current" pid=77278 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[09:16] <mborzecki> [  +0.058639] audit: type=1400 audit(1606122967.283:704): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_vKrjPA/etc/apparmor/" pid=77278 comm="snap-confine" srcname="/var/lib/snapd/snap/core18/1932/etc/apparmor/" flags="rw, bind"
[09:17] <mup> PR snapd#9640 closed: tests/nested/manual/core20-save: verify handling of ubuntu-save with different system variants  <Run nested> <Squash-merge> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9640>
[09:20] <mborzecki> hmmm so restarted apparmor.service once more and it works now, why wasn't that picked up the first time?
[09:34] <mborzecki> https://github.com/snapcore/snapd/pull/9204 didn't manke it to 2.48?
[09:35] <mup> PR #9204: sandbox: track applications unconditionally <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9204>
[09:38] <pedronis> mvo: hi, thanks for reviewing #9679
[09:38] <mup> PR #9679: daemon: start cleaning up api tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/9679>
[09:38] <pedronis> mborzecki: it's marked intentionally 2.49
[09:38] <mvo> pedronis: my pleasure
[09:41] <pedronis> pstolowski: hi, maybe you could give a 2nd review to #9679, sadly it's a bit large and some bits a bit tedious
[09:41] <mup> PR #9679: daemon: start cleaning up api tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/9679>
[09:42] <pstolowski> pedronis: sure
[09:43] <mborzecki> pedronis: yeah, noticed
[09:43] <pedronis> pstolowski: thx
[09:54] <pstolowski> #9590 needs 2nd review
[09:54] <mup> PR #9590: tests: download timeout spread test <Created by stolowski> <https://github.com/snapcore/snapd/pull/9590>
[10:02] <mup> PR snapd#9681 closed: tests: Fix snap-debug-bootvars test to make it work on arm devices and core18 <Simple 😃> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9681>
[10:07] <mup> PR snapd#9683 opened: packaging/arch: sync with AUR packaging <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9683>
[10:52] <mvo> pedronis: I updated 9670, hopefully clearer now
[10:53] <mvo> pedronis: (but no rush of course)
[10:53] <pedronis> I'll look after lunch
[11:16] <mborzecki> google:ubuntu-core-18-64:tests/main/security-dev-input-event-denied sometimes fails on gh, but works when running from local?
[11:17] <mup> PR snapd#9684 opened: devicestate: support "storage-safety" defaults during install (2.48) <Created by mvo5> <https://github.com/snapcore/snapd/pull/9684>
[11:17] <zyga> racy?
[11:17] <zyga> or fallout from the internal snap-device-helper merge?
[11:20] <mvo> pedronis: looks like 9679 is good to get merged too, nice !
[11:23] <mborzecki> mvo: can you land https://github.com/snapcore/snapd/pull/9676 ? the failure on 18.04 is unrelated
[11:23] <mup> PR #9676: bootloader: indicate when boot config was updated <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9676>
[11:29] <mvo> mborzecki: sure
[11:30] <mborzecki> mvo: thanks
[11:32] <mvo> yw
[11:32] <mup> PR snapd#9676 closed: bootloader: indicate when boot config was updated <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9676>
[12:07] <mup> PR snapd#9683 closed: packaging/arch: sync with AUR packaging <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9683>
[12:26] <pedronis> mvo: I'm still confused by the logic in 9670
[12:26] <mvo> pedronis: hm, that's not good
[12:27] <mvo> pedronis: thanks for your comment, I will update the code and the tests to follow your advise
[12:28] <pedronis> mvo: is the same advice I gave the last time fwiw, maybe there's a reason to do it differently?
[12:29] <mvo> pedronis: not really, I think I just forgot over the weekend
[12:29] <pedronis> ok
[13:02] <pedronis> mvo: I stared more at #9526 and something doesn't look right
[13:02] <mup> PR #9526: snapshotstate: add cleanup of abandonded snapshot imports <Created by mvo5> <https://github.com/snapcore/snapd/pull/9526>
[14:38] <mup> PR snapd#9679 closed: daemon: start cleaning up api tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9679>
[14:51] <ijohnson> mvo: I updated the comment on 9680, could you please take a look? thanks
[14:52] <mvo> ijohnson: sure
[15:35] <zyga> hey ijohnson
[16:16] <ackk> hi, is it possible to passthrough settings for limits (specifically LimitNOFILE and LimitNOFILESoft) to a service unit in a snap?
[16:22] <sil2100> mvo: hey! I'm looking at the snapd SRU right now
[16:22] <sil2100> mvo: the SRU bug mentions looking for 2.48 test logs in https://travis-ci.org/github/snapcore/snapd/branches , but that seems to have really old runs like from 3 months ago?
[16:23] <sil2100> mvo: I don't see the 2.48 branch there or any activity since 3 months - did this move somewhere else? If yes, where can I find the test logs?
[16:25] <mvo> sil2100: indeed, I need to update this, we moved to GH actions since
[16:26] <pedronis> mvo: the unit tests are failing in #9526 now
[16:26] <mup> PR #9526: snapshotstate: add cleanup of abandonded snapshot imports <Created by mvo5> <https://github.com/snapcore/snapd/pull/9526>
[16:28] <mvo> pedronis: looking
[16:30] <zyga> pstolowski, thanks
[16:30] <zyga> pstolowski, I replied to some points
[16:30] <pstolowski> zyga: thanks
[16:33] <zyga> pstolowski, I want to rest a little but I'll go through the easy stuff for tomorrow
[16:34] <pstolowski> zyga: no worries, also I can push some trivials if that's ok
[16:34] <zyga> pstolowski, nah, you'll take all the glory and credit then
[16:34] <zyga> and I won't have anything easy to contribute anymore :)
[16:35] <pstolowski> :D
[16:50] <mvo> a second review for 9670 would be great
[17:04] <sil2100> https://github.com/snapcore/snapd/runs/1425950639?check_suite_focus=true <- is this the set of test results for 2.48? I think I'm still a bit new to this whole GH actions work ;)
[17:06] <mvo> sil2100: yes, that is correct, but the spread runner for this is not wired up :/
[17:07] <mvo> sil2100: I can create an artifical run for you, I was looking around and we don't have a run that tests exactly the release (each commit is tested so I can give you the run of the commit before that release)
[17:09] <sil2100> mvo: one for the previous commit sounds fine! I just want to document it on the SRU bug so that we have it handy before proceeding :)
[17:09] <sil2100> I trust you that it's all green anyway
[17:09] <sil2100> (well, green enough for release)
[17:09] <mvo> sil2100: yeah, let me create something artifcial for you while I sort this out
[17:13] <mvo> sil2100: I created https://github.com/snapcore/snapd/pull/9685 for you, I will keep an eye on it and once it's done I can link to it from the sru bug
[17:13] <mup> PR #9685: tests: run tests against 2.48 for the SRU <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9685>
[17:14] <mup> PR snapd#9685 opened: tests: run tests against 2.48 for the SRU <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9685>
[17:24] <sil2100> mvo: thank you!
[17:44] <ijohnson> hey zyga (sorry I missed your ping earlier)
[22:50] <mup> PR snapd#9680 closed: osutil/disks: allow mocking DiskFromDeviceName <Simple 😃> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9680>


[14:55] <pogi1234> hello
[14:55] <pogi1234> anybody here?
[16:19] <nfr> Sorry for asking in this channel, but I didn't find a better one. I have a small ecommerce in Europe. Do you know how to accept payments from India? PayPal does not seem to work in India. Thanks in advance!


[00:31] <rick_h_> Makyo: that error happens once in a blue moon and seems saucelabs related
[13:22] <frankban> guihelp: anyone available for reviewing/QAing https://codereview.appspot.com/83880044 (quickstart)? thanks!
[13:32] <bac> frankban: i will shortly
[13:32] <frankban> bac: thanks
[13:56] <hatch> morning
[13:57] <rick_h_> morning hatch
[13:57] <hatch> hey rick_h_ when you did the nr_cpus=1 did you just put that in the list of the commands when editing the startup?
[13:57] <rick_h_> hatch: have to put it in the right place
[13:57] <rick_h_> where it says splash and such
[13:58] <hatch> oh ok, I thought that might have been the case - I coudlnt' find any docs online about it
[13:58] <rick_h_> change those to noslash noxxxx and add nr_cpus=1
[13:58] <rick_h_> nosplash that is
[13:59] <hatch> ok thanks - man I just want this darn thing on Ubuntu lol
[14:00] <rick_h_> lol yea
[14:00] <rick_h_> thanks for following up and trying
[14:00] <rick_h_> I've been knocked out dead early this week
[14:00] <hatch> https://bugzilla.kernel.org/show_bug.cgi?id=60635
[14:00] <hatch> I am using redfind already....not sure how else to do an efi boot
[14:01] <rick_h_> yea, I think we need to make that clear
[14:01] <rick_h_> the bug linked might not be valid because he's missed we're using refind already
[14:01] <hatch> I wish I knew -anything- about kernels lol
[14:05] <kadams54> Anyone know why MachineList is a LazyModelList and not just a ModelList?
[14:06] <kadams54> Doesn't seem like the performance advantage of LazyModelList would be needed here
[14:07] <kadams54> And I'm depending on change events firing on the machines in the list in order to keep the MachineView up-to-date, which LazyModelList makes less likely.
[14:09] <hatch> kadams54 there could be thousands of machines
[14:09] <hatch> s/could/will
[14:17] <kadams54> hatch: scratching my head over YUI stuff - could I have you take a quick look?
[14:18] <hatch> 2 mins just gota grab my breaky
[14:18] <kadams54> np
[14:20] <hatch> ohh kay link?
[14:21] <kadams54> http://pastie.org/private/hu1ljam1js0lhdtxozxdbw
[14:21] <hatch> yep
[14:21] <hatch> that's right
[14:21] <hatch> :)
[14:21] <kadams54> When I create a Machine and add it to MachineList, the raw object that I get back out of the list has a null displayName
[14:22] <hatch> try foos.create()
[14:24] <hatch> are the returned values actually strings? or is that just in your paste?
[14:24] <kadams54> yes
[14:24] <kadams54> actually strings
[14:25] <kadams54> Paste is taken directly from web inspector console
[14:25] <hatch> does create help?
[14:25] <kadams54> No
[14:25] <hatch> hmm ok lemme look at the lml code
[14:25] <kadams54> http://pastie.org/private/qgxsrjhx5canncqqdqn7ug
[14:26] <hatch> ok I'm going to fire up a jsfiddle here
[14:26] <hatch> or jsbin for that matter
[14:26] <rick_h_> kadams54: foos.items(0).get('displayName')
[14:26] <hatch> it a pojo
[14:27]  * rick_h_ is guessing displayName is an ATTR?
[14:27] <rick_h_> oh nvm then :)
[14:27] <rick_h_> bad guess
[14:27] <hatch> so'ok!
[14:27] <kadams54> LazyModelList stores the objects as POJOs instead of full Models for performance reasons
[14:27] <frankban> kadams54: the displayName is added to machine objects by MachineList.add
[14:27] <frankban> kadams54: it calls _setDefaultsAndCalculatedValues
[14:27] <kadams54> Ah
[14:28] <kadams54> And that's probably overwriting my "0" with a calculated value
[14:28] <hatch> oh there we go :) I was just writing a repro with raw YUI
[14:28] <hatch> heh :)
[14:28] <kadams54> Which is why we get a "null" string
[14:28] <kadams54> Instead of null
[14:28] <hatch> thanks for stepping in frankban
[14:29] <hatch> bleh lifestyle changes taste so bad...
[14:29] <hatch> #dietingisforsuckers
[14:29] <kadams54> heh
[14:30] <kadams54> Thanks frankban - that was the missing piece
[14:31] <frankban> welcome
[14:50] <Makyo> jujugui call in 10
[14:50] <rick_h_> I think Makyo has his alarm set for 11min vs 10 :P
[14:52] <Makyo> 10 minutes by my phone, just whenever that goes off.
[14:52] <Makyo> (but now I'm totally doing that.  Thanks rick_h_ :D )
[14:58] <luca__> rick_h_: Makyo hatch can we have a call once your off your call? :)
[14:59] <hatch> we can
[14:59] <rick_h_> luca__: rgr
[14:59] <luca__> thanks
[15:01] <frankban> bac: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/view/head:/doc/bazaar-usage.txt
[15:04] <bac> thanks frankban
[15:11] <rick_h_> luca__: https://plus.google.com/hangouts/_/canonical.com/daily-standup
[15:12] <luca__> just saving my doc
[15:22]  * frankban biab
[15:54] <hatch__> brb
[15:58] <frankban> rick_h_: so, should we keep joyent support out for now? I know our exception is for fixing quickstart on newer juju-core. I wonder if that's to be intended as exclusive i.e. only the buf fix, no other developments/changes added in the meanwhile
[15:58] <kadams54> I was just getting ready to submit a pull request, but after rebasing to latest on develop, I can't get to the machine view anymore
[15:59] <rick_h_> kadams54: hit the machine view tab in the nav
[15:59] <kadams54> Yeah, I did.
[15:59] <kadams54> Nothing
[15:59] <rick_h_> kadams54: oh hmm, that works in comingsoon
[15:59] <rick_h_> http://comingsoon.jujucharms.com/:flags:/il/mv/
[15:59] <rick_h_> hit machine view button?
[16:00] <rick_h_> kadams54: if it doesn't work locally make clean-all maybe? Or check for errors in console/etc
[16:00] <kadams54> Will do
[16:01] <kadams54> *sigh*
[16:01] <kadams54> Error in my code
[16:01] <rick_h_> frankban: can you write up an email about the joyent provider now landing and our wish to have that in quickstart to james page and robie and copy me?
[16:01] <rick_h_> frankban: we'll ask if it'll be possible, if not. Let's hold on landing that branch until the bugs land first
[16:01] <rick_h_> so we can release just what we promised them, a bugfix release
[16:02] <rick_h_> frankban: and if so, then we can follow up with the joyent under whatever rules we can get that in under
[16:02] <rick_h_> frankban: and if not, then landing joyent in quickstart will be the start of the new ppa releases, but not in trusty
[16:02] <frankban> rick_h_: sounds good
[16:10] <kadams54> guihelp https://github.com/juju/juju-gui/pull/222 is ready for review and QA (list machines in machine view)
[16:11] <Makyo> kadams54, on it
[16:14] <kadams54> thanks
[16:21] <rick_h_> jujugui going to go afk for some lunchable. biab
[16:21] <hatch> enjoy
[16:22] <frankban> kadams54: so, do we display both top level machines and containers in that part of the machine view?
[16:23] <kadams54> Not entirely sure. There's a machine column and a container column, so I'd guess so?
[16:23] <kadams54> My card was for listing the machines in the machine column, so the container column is still non-functional
[16:26] <frankban> kadams54: if I read your diff correctly, you are listing all the machines (db.machines.toArray()). That would include also the containers. It is possible to only list top level machines by using machines.filterByParent(null)
[16:27] <kadams54> Ah, did not realize the collection contained both machines and containers…
[16:27] <kadams54> Is there a reason containers aren't in a separate collection?
[16:28] <frankban> kadams54: it's not a separate entity in juju-core itself, and also they share almost all the properties. it's a tree, where a phisical machine can host containers and containers can host other containers etc.
[16:38] <hatch> rick_h_ “Arguing with an engineer is like wrestling with a pig in mud – you realise far too late it is enjoying it”  rofl
[16:45] <kadams54> frankban: got it. Will modify the code accordingly.
[16:45] <frankban> kadams54: cool thanks
[16:46] <kadams54> hatch: Nice. I'll have to remember that one.
[16:46] <hatch> I want a tattoo of that haha
[16:46] <kadams54> Your wife might argue with you about that.
[16:47] <hatch> what if it's in Japanese? Chinese? Then I'd be part of the cool kids
[16:47] <hatch> I'd just tell everyone it means "Love"
[16:47] <hatch> lol
[16:49] <hatch> Makyo I just booted up vagrant and it's creating a new image.....
[16:49] <hatch> any idea how I would point it to the old one again?
[16:49] <Makyo> Um.
[16:50] <Makyo> I think it's in a .vagrant or something folder in ~?
[16:51] <rick_h_> hatch: :)
[16:52] <frankban> rick_h_: had a chat with robie in #juju, joyent is out, the other parts of the plan sound great to him. I think landing joyent later next week is fine.
[16:52] <rick_h_> frankban: rgr thanks
[17:00] <hatch> rick_h_ want to have a quick discussion about this branch
[17:10] <rick_h_> hatch: sure link
[17:10] <hatch> https://plus.google.com/hangouts/_/7ecpj9soau6943l97kuv7qnknc?authuser=1&hl=en
[17:23] <bac> hi frankban, when bootstrapping joyent, after creating an environment with quickstart, i get http://paste.ubuntu.com/7199671/
[17:24] <frankban> bac: uhm, is this the 1.18 branch?
[17:24] <bac> i think so.  let me double check
[17:25] <bac> frankban: yes, it is using the version i built using the 1.18 branch.  however, 'juju version' shows 1.19.0-trusty-amd64
[17:26] <bac> frankban: i merged 1.18 into my lw checkout of juju-core trunk.  is that correct?
[17:28] <frankban> bac: I don't think so, you should just branch the 1.18 branch and switch to that. I guess trunk includes other changes
[17:28] <frankban> bac: my 1.18 branch is 1.17.8-saucy-amd64, bzr revno 2257
[17:29] <bac> frankban: i'm unsure how to do that with lightweight checkouts.  usually i do a 'bzr switch -b', which gives me a copy of trunk.  how would i get a checkout of 1.18 in place?
[17:30] <frankban> bac: also, before compiling "godeps -u dependencies.tsv" can be a good sanity check (go get launchpad.net/godeps)
[17:32] <hatch> poor bws-icon
[17:32] <hatch> delete!
[17:32] <frankban> bac: I followed the bzr docs in trunk, and so I created a shared repo outside the $GOPATH, in ~/devel/juju-core. There I can just bzr branch some-branch. at that point you can "bzr switch {target}" from the juju-core in $GOPATH/src/...
[17:33] <bac> frankban: ah, gotcha.  i'm used to just working in the other workspace
[17:35] <frankban> bac: yeah the configuration in that doc is cool because you have both the structure go requires ($GOPATH/src/launchpad.net/juju-core) and a real shared repo to work on, given that the former is bound to the real repo as a lightweight checkout. So, basically, $GOPATH/src/launchpad.net/juju-core is just what we usually call "sandbox"
[17:36] <bac> frankban: right.  i just didn't know you could manually insert a different branch in ~/src/juju-core
[17:36] <frankban> time to go, have a nice evening
[17:37] <bac> frankban: wait!
[17:37]  * frankban waits
[17:37] <bac> frankban: for joyent are the sdc user/keys the same ones for manta?
[17:37] <frankban> bac: yes
[17:37] <bac> ok.  perhaps we can make that clearer in the field descriptions
[17:38] <bac> or maybe make the manta ones optional and force them to be the same if blank
[17:39] <frankban> bac: yes, that can be an improvement. FWIW my envs.yamls looks like http://pastebin.ubuntu.com/7199750/
[17:46] <bac> frankban: if you're still around have you seen this before http://paste.ubuntu.com/7199773/
[17:47] <kadams54> Makyo, frankban: FYI, updated https://github.com/juju/juju-gui/pull/222 to only pull top-level machines. Also realized I had one commit that didn't get pushed.
[17:47] <frankban> bac: no, but I guess your previous attempt left something there, and juju-core got confused by the binary change.
[17:47] <Makyo> kadams54, cool, thanks.  Was having trouble on this comp, switched to Air to find vagrant out of date.  Will switch back.
[17:48] <bac> frankban: huh.  ok, i'll poke around.  thanks.  won't bug you again.  good night.
[17:48] <frankban> bac:  you can try "juju destroy-environment joyent -y --force" and check nothing is in ~/.juju/environments/
[17:48] <rick_h_> kadams54: tossed a few comments in for fun
[17:48] <rick_h_> kadams54: which might be out of date now it sounds like
[17:52] <frankban> bac: cool, there is no rush in landing this branch, so if you are blocked we can take a look at that together tomorrow
[17:53] <kadams54> rick_h_: yeah, saw those. I caught the constructor one early enough, but will update the tests as requested on the next pass through the code (after another other reviews).
[17:53] <rick_h_> kadams54: cool
[17:53] <rick_h_> kadams54: remind me in the call I'll mention how the initializer and some other 'magic' methods work
[17:54] <hatch> think C classes
[17:54] <hatch> that's how initializers work :P\\
[17:56] <kadams54> hatch: I haven't programmed in C since college, over a decade ago :-)
[17:56] <rick_h_> hatch: right but other things like render and such can be cascaded (at least for widgets/etc)
[17:56] <hatch> base derrived classes yeah
[17:56] <hatch> kadams54 haha yeah same here
[17:56] <kadams54> Yeah, I was thinking that constructors needed to cascade when I wrote that
[17:57] <kadams54> Then I remembered this is YUI, not plain JS.
[17:57] <rick_h_> there's a good yuiconf talk on video for how base works
[17:57] <kadams54> And this was an initialize method, not a constructor
[17:57] <kadams54> Hit me with the link
[17:59] <hatch> rick_h_ kadams54 https://docs.google.com/file/d/0By84yWo_5i6LYXNsdnhHV2Z2TUU  aww yeah C++
[18:00] <hatch> see that one has a 3.5" floppy on it!
[18:00] <hatch> lol
[18:18] <rick_h_> kadams54: https://www.youtube.com/watch?v=_zhQIfT7g58&index=6&list=PLF49A40DA7A11F08A ftw
[18:19] <kadams54> Woot
[18:19] <hatch> ohh yeah I remember that talk
[18:19] <rick_h_> one of my fav yui talks
[18:19] <hatch> yeah luke is great
[18:19] <hatch> at smugmug now
[18:54] <bac> rick_h_: just a heads up, manage.jujucharms.com/heartbeat currently shows an API2 failure.  it is a false positive caused by us currently not featuring any charms, just bundles.
[18:57] <Makyo> No plumber yet, but we did get our new doors delivered.  Bonus.
[18:59] <hatch> Makyo might be time to fire this guy
[18:59] <hatch> :)
[18:59] <bac> Makyo: so you've had this leak at the meter for weeks now?
[18:59] <Makyo> Yep.
[18:59] <bac> yowza
[18:59] <Makyo> I just got a water bill, actually.
[19:00] <Makyo> $286.04
[19:01] <Makyo> https://www.dropbox.com/s/jregju31mdzuuhc/IMG_20140403_130049.jpg
[19:02] <hatch> ouch!
[19:06] <hatch> rick_h_ https://github.com/juju/juju-gui/pull/223 WIP
[19:06] <hatch> this doesn't have the tests fixed but I'd like some third party input
[19:18] <Makyo> hatch, ping when you have a second.
[19:19] <Makyo> Want to get a good ECS card.
[19:19] <hatch> hmm I'm just cooking lunch atm
[19:20] <hatch> can we do it in 45mins or are you not doing anything now?
[19:20] <Makyo> Will do lunch too, finish this review.
[19:20] <Makyo> 45 mins is fine
[19:20] <hatch> sounds good
[19:35] <bac> rick_h_: i'm stuck working with the juju guys trying to get the joyent provider to work.  that's kind of like QA, isn't it?  :)
[19:47] <rick_h_> bac: hah, sorry catching up
[19:49] <rick_h_> bac: oh lol for your qa day, yea we'll call it
[20:02] <hatch> Makyo whenever you're ready, rick_h_  you may want to be part of this discussion as well
[20:03] <Makyo> hatch, sure
[20:03] <rick_h_> hatch: rgr
[20:03] <hatch> creating room
[20:03] <hatch> https://plus.google.com/hangouts/_/7acpjdgv54v5pnjt0fc9v0snjs?authuser=1&hl=en
[20:17] <hatch> rick_h_ btw there have been some developments wrt the kernel bits - tonight I'm going to give them a try
[20:17] <rick_h_> hatch: thanks, let me know how it goes
[20:17] <hatch> apparently both of us have been installing Ubuntu incorrectly
[20:18] <hatch> we need to use EFI mode instead of legacy
[20:18] <rick_h_> yea, not sure how that happened
[20:18] <hatch> yeah I'll definitely keep notes
[20:18] <rick_h_> didn't really see an 'efi' mode during install from the usb cd
[20:18] <hatch> yeah neither did I...
[20:40] <hatch> w00t down to 9 failures
[20:45] <rick_h_> hatch: that sounds darn right reasonable :)
[20:45] <hatch> :shipit: amiright?
[20:45] <rick_h_> and lies
[20:47] <hatch> oo the tests found a real bug
[20:47] <hatch> lookatthat
[20:48] <rick_h_> #so-thats-how-it-works :)
[20:49] <hatch> haha
[20:49] <rick_h_> as much I tests are a pita, I so love them when they catch a bug before it lands
[20:57] <hatch> somhow I deleted three tests and fixed one and still have 8 failures....
[21:36] <hatch> rick_h_ in test_browser_app.js browser subapp display tree there is a `hits` object
[21:37] <hatch> why do they default to true?
[21:37] <hatch> That seems backwards?
[21:37] <hatch> I feel like I'm missing something
[21:37] <rick_h_> hatch: k
[21:38] <rick_h_> hatch: they default to true?
[21:38] <rick_h_> hatch: there's a 'resetHits() method
[21:38] <hatch> ohh ok I broke something
[21:38] <hatch> right
[21:38] <rick_h_> that gets called in setup and manually for multi dispatch tests
[21:38] <hatch> right
[21:38] <hatch> sorry
[21:38] <hatch> hmm
[21:41] <hatch> test failures when things work in the real world...not fun
[21:41] <rick_h_> hatch: let me know if you want another set of eyes
[21:48] <hatch> thanks but I just skipped the final two because they would need state
[21:55] <hatch> rick_h_ ok pushed....would be awesome if you could find some time to qa/review
[21:55] <hatch> keeping in mind the follow-up will be to properly implement the state
[21:55] <rick_h_> hatch: rgr
[21:55] <hatch> thanks
[21:55] <rick_h_> yea, realize the whole 'test and build state' card here didn't get there because of the viewmode removal
[21:55] <rick_h_> but smaller branches == better
[21:56] <hatch> yeah agreed
[21:57] <hatch> I did remove over 1000 lines in total
[21:57] <hatch> that's awesome lol
[21:57] <rick_h_> yea, I mean this is good, just time consuming
[21:57] <rick_h_> between this and inspector we're paying a price for the better code hopefully
[21:58] <rick_h_> but let's try not to find anything else to rewrite :)
[21:58] <hatch> lol is there anythign else?
[21:58] <rick_h_> shush, you'll send back luck our way
[21:59] <hatch> haha
[21:59] <rick_h_> hehe...except I'm not kidding
[22:01] <huwshimi> Morning
[22:01] <rick_h_> morning huwshimi
[22:03] <huwshimi> rick_h_: Has our ci broken?
[22:03] <rick_h_> huwshimi: not that I'm aware of. What's up?
[22:03] <rick_h_> huwshimi: you had a legit failing test. You replied that it could be removed, but never updated and removed the test
[22:03] <huwshimi> rick_h_: Well, all the current MPs have builds that have started but not completed.
[22:03] <rick_h_> huwshimi: I was going to ask what happened yesterday and if there was something that got stuck
[22:04] <rick_h_> huwshimi: oh heh, yea that's broken
[22:04] <rick_h_> sec, have to stop
[22:05] <rick_h_> huwshimi: should be good to go hopefully
[22:05] <huwshimi> Ah great
[22:15] <rick_h_> hatch: replies in bound, will start qa
[22:15] <hatch> thanks I'll take a look
[22:15] <huwshimi> rick_h_: What should I tackle today? I see kyle is already working on the machine panel tokens...
[22:16] <rick_h_> huwshimi: he's working on the data, but not the tokens
[22:16] <rick_h_> bah, he's gone. I thought he would get that landed
[22:16] <rick_h_> huwshimi: what were you working on yesterday? Is that done then?
[22:16] <huwshimi> rick_h_: Ah, I thought there were two cards about tokens and now there's only one so I assumed he must have done it. I must have mis-remembered.
[22:17] <rick_h_> huwshimi: ah well his card says 'using deployed unit token' but it's not ready yet so he's just dumping out text
[22:18] <rick_h_> huwshimi: so I'd say to start looking at the token I suppose.
[22:19] <rick_h_> huwshimi: https://drive.google.com/a/canonical.com/?urp=https://docs.google.com/&pli=1#folders/0B_l975nRB6BuM2p4eTZMSXpWRTQ
[22:19] <rick_h_> we can go over them during hte call
[22:20] <huwshimi> rick_h_: That'd be great, thanks!
[22:28] <rick_h_> hatch: qa notes added
[22:29] <rick_h_> hatch: I ack that not all are in/for this branch. Just noting things that are broken.
[22:29] <hatch> ok cool
[22:29] <hatch> looking
[22:30] <hatch> line reflow?
[22:31] <rick_h_> otp
[22:31] <hatch> I actually prefer when there isn't one long line and then another word on the next line :)
[22:31] <rick_h_> hatch: oh yea, well the limit is 79, not 20 and 15
[22:31] <hatch> limit.....not required :P
[22:32] <rick_h_> it looks odd imo and breads readability and I bet one or two of those will fit on one line now
[22:32] <rick_h_> fighting on everything :P
[22:34] <hatch> hah no it's just going to take me a while to reflow all of these
[22:34] <rick_h_> open in vim, run gq
[22:34] <rick_h_> it's one command :)
[22:35] <hatch> that doesn't require a plugin?
[22:35] <rick_h_> no, I don't believe it does
[22:35] <hatch> hmm ok I'll have to download vim
[22:35] <rick_h_> http://www.methods.co.nz/asciidoc/chunked/ch36.html
[22:35] <rick_h_> w...t...f doesn't it exist in your virtualmachine?
[22:35] <hatch> or did you just want me to do those two lines
[22:35] <rick_h_> ssh, vim xxxx.js
[22:35] <hatch> not the entire file?
[22:35] <rick_h_> the cases of those comments
[22:35] <hatch> oh ok, then done
[22:35] <hatch> :)
[22:36] <rick_h_> some of them jump out as looking stupid so I noted them in review
[22:37] <hatch> that's an interesting functionality of vim
[22:37] <hatch> to reflow a line
[22:37] <rick_h_> very handy when editing blocks of text/comments and emails
[22:38] <hatch> yeah if you don't use a real client :P
[22:47] <hatch> rick_h_ so changes are made - I'm not clear on your qa notes, did you want me to fix those things?
[22:51] <rick_h_> hatch: https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.dd77sn7kjl6unba21lutdr0p70?authuser=1
[23:07] <hatch> is there an aus call?
[23:07] <hatch> or did I miss it?
[23:38] <hatch> achievement: Ubuntu 14.04 on MBP
[23:46] <rick_h_> hatch: missed it, it before you and I talked
[23:50] <huwshimi> hatch: Did you get all the touch packages installed as well? No idea why I have them...
[23:51] <hatch> huwshimi I don't know what that is
[23:52] <hatch> :)
[23:52] <hatch> every few minutes it pops up with a system error report
[23:52] <hatch> so it's not really usable
[23:52] <huwshimi> hatch: You don't know what Ubuntu Touch is?
[23:52] <hatch> and I can't actually shut it down outside of the terminal either
[23:52] <hatch> oh the Ubuntu Touch packages
[23:52] <hatch> I don't think I got those
[23:53] <huwshimi> So strange...
[23:53] <hatch> I have to find where I file bugs
[23:53] <hatch> the inability to shut down is kind of a big one
[23:54] <huwshimi> hah
[23:55] <hatch> switching to wifi
[23:56] <rick_h_> sudo shutdown -h now
[23:56] <rick_h_> or per zsh alias 'shut'
[23:56] <rick_h_> kadams54: hey, around?
[23:56] <kadams54> I am now :-)_
[23:56] <rick_h_> kadams54: how's your branch? Is it ready to land? huwshimi is doing some work with the token part that will build on it
[23:57] <rick_h_> kadams54: I had thought your branch might get in before he got running
[23:57] <kadams54> Ah, yeah… let me get that pushed out
[23:57] <rick_h_> kadams54: ty much
[23:57] <rick_h_> huwshimi: ^
[23:57] <kadams54> np
[23:58] <rick_h_> huwshimi: what did you need to do? Just install the packages mentioned in the bug report?
[23:58] <huwshimi> kadams54, rick_h_: Brilliant, thankyou!
[23:59] <huwshimi> rick_h_: Somehow when I upgraded to Trusty it installed all the Ubuntu Touch packages as well.
[23:59] <rick_h_> huwshimi: hah
[23:59] <hatch__> huwshimi does it do anything different with those packages?


[00:04] <lucassec> Opa
[00:05] <lucassec> Alguem teria algum pdf ou documento sobre linux, gostaria de entender mais sobre
[09:02] <xu-irc4w> buenas alguno despierto tengo una duda respecto a la instalacion
[09:03] <xu-irc4w> tengo un pc con windows q el ordenador me va lento voy a cambiar a xubuntu pero quiero saber el tema de los drives los reconocera automaticamente o tendre que instalarlos
[09:04] <xu-irc4w> desde algun repositorio , el tema es que mis pc sus drivers no soy comunes en linux
[09:06] <xu-irc4w> hi
[09:06] <xu-irc4w> ?
[09:40] <tomreyn> !es | xu-irc4w
[09:40] <tomreyn> xu-irc4w: if you also speak english, feel free to ask here
[10:57] <xu-irc4w> hello all, sorry for my spanish
[10:58] <xu-irc4w> 254 / 5000
[10:58] <xu-irc4w> Resultados de traducción
[10:58] <xu-irc4w> I have a pc with windows that the computer is slow for me I am going to change to xubuntu but I want to know the issue of the drives, will it automatically recognize them or I will have to install them
[10:58] <xu-irc4w> from some repository, the issue is that my pc's drivers are not common in linux
[11:00] <diogenes_> xu-irc4w, boot it live off an USB drive and if it boots and you can connect to internet then all is well.
[15:04] <MariaDiaz> diogenes_, you probably remember me. I've bought a SD (instead of a USB), installed Xubuntu 21.04 and the same problem remains. 'Started File System Check Daemon to report status.'
[15:04] <diogenes_> MariaDiaz, SD card?
[15:05] <MariaDiaz> yeah. I installed Xubuntu on it
[15:06] <diogenes_> sd card is no good, they're even slower than USB drives.
[15:08] <MariaDiaz> I know :) I've bought that one which is a bit faster than other ones. Also it is not convenient to have an opportunity to break the both USB and its port
[15:09] <MariaDiaz> Suddenly, unintentionally
[15:13] <diogenes_> MariaDiaz, there are tiny thumdrives which are only a few mm outside so they are safe.
 MariaDiaz, there are tiny thumb drives which are only a few mm outside so they are safe.
[15:17] <MariaDiaz> They must be expensive, I suppose
[15:19] <MariaDiaz> Also… I wonder… if removing the HDD will solve the problem or not.
[15:20] <MariaDiaz> If it doesn't solve the problem, then what is it
[15:20] <tomreyn> those are not expensive at all
[15:21] <diogenes_> MariaDiaz, this is what you need: https://www.aliexpress.com/item/32345359354.html?spm=a2g0s.90423<IP_ADDRESS>424c4dC8M2JT
[15:21] <diogenes_> 3 dollars for 16 GB.
[15:22] <diogenes_> i wouldn't recommend to buy with a larger capacity because it will be slower.
[15:23] <diogenes_> i'm running Debian with persistence off one of such USBs drives and it runs just fine.
[15:26] <MariaDiaz> What if I buy it and it won't boot again? :D anyway that drive you suggested is cool! I bought mine for 4 dollars, 32 GB
[15:56] <MariaDiaz> This time (when it is installed on SD) fsck.mode=skip helped finally. Since I'll have the boot menu setting changed to fsck.mode=skip, I'll probably have no problem anymore. Thanks for all the knowledge and the help!
[15:59] <diogenes_> MariaDiaz, you've got a warrior spirit :)
[16:29] <xu-irc12w> Is there a way of removing all non-english fonts from the font collection?
[16:45] <tomreyn> yes, but you'll never find out now.


 I have installed ubuntu SMP, not able to get eth1 working.... I am able to see eth1 in dmesg and lspci... but not able to configure the interface...
[07:38] <Tm_T> SMP?
[07:38] <bazhang> why would eth1 appear in lspci or dmesg
[07:38] <bazhang> that sounds like something from ifconfig
[07:39] <Tm_T> bazhang: it does appear on both, possibly
[07:39] <bazhang> on lspci? nope
[07:40] <Tm_T> not as "eth1" but as the actual device
[07:41] <bazhang> he's very very confused as to how to describe a problem then
[09:03] <IdleOne> rejected
[09:03] <IdleOne> :P
[09:04] <Tm_T> IdleOne: I thought bitcoins is religion related anyway
[09:04] <bazhang> hah
[10:23] <bazhang> is github the paste site or something?
[10:23] <bazhang> +new
[10:25] <elky> gist? it gives people control over the visibility after pasting, so it's kinda popular
[10:25] <elky> and they don't lose their pastes, etc
[10:26] <bazhang> ok thanks elky
[10:26] <bazhang> just noticed a lot of those recently
[10:27] <bazhang> gist.github etc pastes
[10:27] <elky> also, everyone who has github accounts seems to use it because it's open in their browser already kinda thing
[10:27] <bazhang> right, that makes sense
[10:28] <elky> i kinda like it, github is far more stable than the generic pastebins
[14:16] <Myrtti> ubuntulog seems to be missing from #ubuntu, has been for some time
[14:17] <elky> probably since the split-o-rama last week
[14:17] <Myrtti> yeah
[15:58] <Myrtti> hi zerick
[16:04] <zerick> Hi Myrtti
[16:05] <Myrtti> zerick: how can we help you today=
[16:07] <zerick> Myrtti: I see, this channel is not kind for support, isn't it?
[16:08] <Myrtti> zerick: not really no, see /topic
[16:08] <zerick> Myrtti: bytes!
[16:09] <LjL> nibbles!
[16:10] <Myrtti> boggles!
 Need help Hi what's the actual'delete' key during a Unix session on a PDA with a trackball?
[18:22] <bazhang> question of the day
[18:55] <tonyyarusso> Ask him if 2002 is nice.
[19:03] <jbroome> hahah
[19:06] <bazhang> I would wager that ronald_ is ronald_m , a known issue
 sup fools
[21:00] <bazhang> and /amsg 'd to multiple channels
[21:01] <Fuchs> what exactly did you expect from him? Now it is not as if he was very unknown on this network ... and yes, might need an eye on. Note that he is not very easy to deal with, being blunt might very well result in spamming.
[21:02] <bazhang> yes, true. and he's gone as well now
[21:03] <bazhang> I was wondering, the <disconnected by services> quit message: is that staff induced?
 Ubuntu is extremly unstable since latest 12.10 installation. It is even unusable. Could anyone advise?
[22:42] <bazhang> thats not vague at all
 I have an issue... I just installed Xubuntu and I am unable to find MS Paint