[00:00] <ebroder> Yeah, I saw that, too
[00:01] <ion> Loading all the stuff needed for a graphical plymouth before ureadahead does its thing would defeat the purpose of ureadahead, but printing a line of text wouldn’t.
[00:01] <jdong> "Loading loading screen...."
[00:01] <jdong> :)
[00:01] <jdong> is that like Windows 7's "calculating time remaining"?
[00:01] <ebroder> If I'm basically trying to create a livecd rootfs with the nvidia drivers baked in, what do I need to do? Install nvidia-current, drop in an xorg.conf, anything else?
[00:02] <ion> Plymouth’s purpose is not a loading screen. It’s multiplexing interaction between the user and startup programs.
[00:03] <cjwatson> well, plymouth yes, plymouth-splash not necessarily
[00:03] <cjwatson> I suspect we are in agreement from different directions, though
[00:09] <jdong> ion: sure, but given that it also functions as a loading screen, it looks a little bit confusing
[00:09] <jdong> ion: especially on machines with poor IO performance
[00:10] <ion> Yes, a dozen seconds of black screen isn’t optimal.
[00:11] <lilmonsta> hello all , apolagies for asking but is the 10.04.1 release still due today?   would it be the daily iso listed as 16.1?
[00:12] <ion> We should do what Windows™ does: drop the readahead stuff, generate (and keep updating) a model of disk usage patterns and use idle time to reorder disk blocks for optimal startup times. :-P
[00:13] <jdong> ion: theirs also includes a readaheader
[00:14] <ion> ok
[00:14] <jdong> it does some interesting throttling stuff though to minimize the devastation if the readahead info is really wrong (tm)
[00:14] <jdong> like for us, if you put 5000 random files in the readahead pack, your boot performance will really tank :)
[00:14] <jdong> (on HDD)
[00:15] <penguin42> (I was thinking Maverick is currently feeling slower at boot than lucid - but I haven't timed it)
[00:15] <jdong> my two Maverick machines at work here are reiser4 and btrfs
[00:15] <jdong> one doesn't support readahead, the other is slower than NFS to asia.
[00:15] <ebroder> Oww. You must not like your data
[00:15] <jdong> thanks to 2.6.35
[00:16] <jdong> haha experimental setup :)
[00:16]  * ajmitch thought all your setups were experimental
[00:16] <jdong> it is kind of a shame that it takes 7 hours 30 minutes to install from the alternate CD on btrfs in Maverick
[00:16] <jdong> wonder if we want to roll back that commit for ubuntu-maverick.git
[00:17] <RAOF> It's more of a shame that installing 80 updates takes 2 hours on btrfs.
[00:17] <jdong> (or cross our fingers and hope Oracle has a patch)
[00:17] <jdong> RAOF: I got pissed enough to locally revert that
[00:17] <ajmitch> RAOF: that sounds worse than my laptop :)
[00:17] <jdong> http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-unstable.git;a=commit;h=5da9d01b66458b180a6bee0e637a1d0a3effc622
[00:17] <jdong> that thing
[00:17] <RAOF> jdong: I got pissed enough to take an image (as it seems by btrfs partition is interestingly broken) and reformat to ext4
[00:18] <jdong> HAHAHA
[00:18] <jdong> ok that works too!
[00:18] <ion> Meh. I’m counting days until Oracle drops the btrfs project and instantly starts suing everyone using/developing/distributing it for infringing on their Imaginary Property. :-P
[00:18] <jdong> ion: well brtfs probably does violate the crap out of the ZFS patent portfolio
[00:20] <RAOF> chrisccoulson: Isn't it a bit late for you to be joining #ubuntu-devel? :)
[00:29] <chrisccoulson> RAOF, oh, i must have got disconnected for a bit ;)
[00:33] <RAOF> Aaah, ext4.  < 10 minutes to download and install 300 packages.
[00:34] <slangasek> wait, are you extolling ext4 because of how fast dpkg runs on it?
[00:35] <jdong> haha.
[00:36] <RAOF> slangasek: In comparison to how dpkg runs on *btrfs*, that's practically negative time :)
[00:37] <slangasek> interesting
[00:37] <RAOF> (at least in maverick)
[00:37] <lifeless> RAOF: good or bad on btrsfs?
[00:37] <RAOF> lifeless: Terrible on btrfs.
[00:37] <lifeless> let me guess
[00:37] <lifeless> fsync?
[00:37] <RAOF> On the order of 2 hours to install 80 already downloaded updates
[00:38] <RAOF> I'm not sure that it is fsync, actually, although my libeatmydata testing wasn't particularly rigourous.
[00:38] <lifeless> ok
[00:38] <lifeless> any ideas?
[00:38] <lifeless> and does eatmydata take care of the fsync variants ?
[00:38] <RAOF> jdong's already posted a link to the patch (series?) which causes a ~10x regression in write-heavy loads that's in Maverick
[00:39] <lifeless> (sync, fsyncdir)
[00:39] <RAOF> I think libeatmydata does, yes.
[00:39] <RAOF> There's an LP bug about this, too.
[00:42] <jdong> lifeless: and no, eatmydata doesn't take care of the btrfs thing. It has to do with delayed allocation not truly delaying allocation, forcing way more tree operations than needed
[00:42] <lifeless> jdong: thanks
[00:43] <jdong> Chris Mason had triaged the bug though and says he's working on a patch
[00:43] <RAOF> bug #601299 , if you're interested.
[00:43] <jdong> (two weeks ago)
[00:43] <jdong> wow, 12 hours to set up on a SSD
[00:43] <jdong> impressive!
[00:44] <jdong> oh nvm it's an Asus SDHC-on-a-card "SSD"
[00:45] <chrisccoulson> eatmydata is such a cool name. it almost makes me feel compelled to use it all the time
[00:46] <jdong> oh just patch eglibc if you're gonna do that ;-)
[01:20] <djzn> folks, 10.04.1 --- any hopes for tonight still ? or probably another 7 days...?
[01:36] <skat_> djzn, looking likely.   #ubuntu-release is fairly active ;)
[02:22] <djzn> so we don't get 10.04.1 tonight.....
[02:23] <ScottK> djzn: I wouldn't assume that.
[02:23] <ScottK> I guess it depends on when tonight ends for you.
[02:23] <djzn> ScottK: it ends in 1:30 hour.... -3.00 GMT
[02:23] <djzn> lol
[02:24] <ScottK> You might yet then.
[02:25] <djzn> ScottK: how can you be so sure... this has been postponed for a few days... yet, no sign of isos....
[02:27] <ScottK> I'm somewhat involved in the effort.
[02:29] <djzn> ScottK: I could notice that...
[02:31] <djzn> ScottK: I feel a hint.... that everything is already done... ISOs are ready... the thing is... there are several types of ISOs and each of them had to be produced.. the netbook one, the alternate one, even the DVD had to be made....
[02:32] <djzn> ScottK: But I am not sure... still a Fix Commited bug laying....
[03:21]  * ScottK was going to tell him it's out.
[03:21] <ajmitch> oh well, just a little late :)
[03:22]  * ajmitch wonders when the NZ mirrors will have it
[03:23] <ScottK> At least natty will be less typing than maverick.
[03:24] <ajmitch> but getting people to spell narwhal properly will be fun
[03:24] <ajmitch> At least it's not drapper :)
[03:32] <ajmitch> great, looks like one of the nz mirrors just has a recursive symlink
[03:58]  * huntz0r is away: I'm busy
[03:58] <ion> Thanks for the information!
[04:02] <huntz0r> bloody xchat...
[05:43] <pitti> Good morning
[05:44] <pitti> kirkland: pong
[05:44] <pitti> smoser: yup, will do ASAP
[07:32] <dholbach> good morning
[07:38]  * mneptok looks left
[07:38]  * mneptok looks right
[07:38]  * mneptok junps up and down on dholbach
[07:38] <mneptok> MOIN!
[07:38] <dholbach> hi mneptok
[07:38] <mneptok> *tacklehug*
[07:40] <ajmitch> that's a nice enthusiastic greeting
[07:42] <TheMuso> Brutally so.
[07:42] <TheMuso> :)
[07:43] <dholbach> :-)
[08:46] <Sarvatt> were the non-LTS ports archives before jaunty moved to another server or were they wiped out completely?
[08:52] <tjaalton> Sarvatt: try http://old-releases.ubuntu.com
[08:54] <Sarvatt> phew, thanks tjaalton!
[08:57] <tjaalton> this is weird, mounting Maple14 cdrom doesn't work otherwise but manually
[08:57] <tjaalton> both on lucid & maverick
[09:11] <soren> tjaalton: The maple cdroms are rather special, irrc.
[09:11] <soren> iirc, even.
[09:11] <soren> tjaalton: I believe it will look different depending on whether you mount it from linux, windows or mac.
[09:12] <soren> tjaalton: ...and it'll look different depending on whether you mount the iso like you normally would or if you look at it through one of the userspace tools to inspect iso's.
[09:13] <soren> tjaalton: In short, I'm not surprised some things act up. They shouldn't, but I'm not surprised :)
[09:15] <tjaalton> soren: ah, could be like that yes
[09:16] <tjaalton> well, whatever tries to automount them should be fixed to support those I suppose :)
[09:24] <tjaalton> soren: worked on jaunty though, so sounds like a regression to me ;)
[09:24] <tjaalton> (just tested it)
[09:27] <soren> tjaalton: I remember having problems in... err...
[09:27]  * soren rewinds his brain a couple of years
[09:27] <soren> err.. edgy, it must have been.
[09:29] <tjaalton> soren: ok.. now it seems to be udev handling the mounts?
[09:31] <soren> tjaalton: No idea.
[09:33] <cjwatson> udev won't be mounting things itself.  perhaps udisks.
[09:34] <tjaalton> right
[09:34] <sivang> hi all
[09:36] <sivang> What are the tools commonly used to allow participants not in physical presence to be part of a developer's summit? http://gobby.0x539.de/trac/ comes to mind, but what other tools have past summits used?
[09:51] <bilalakhtar> bdrung: there?
[09:51] <bdrung> bilalakhtar: yes
[09:52] <bilalakhtar> bdrung: a main patch, ready?
[09:52] <bilalakhtar> bdrung: patch has been accepted in MeeGo
[09:52] <bilalakhtar> package: gnome-disj-utility
[09:52] <bilalakhtar> K
[09:52] <bdrung> bilalakhtar: i will put it on my list. i will have time for it in the evening
[09:53] <bdrung> bilalakhtar: can you give me the lp?
[09:53] <bilalakhtar> bdrung: Thanks a lot! https://code.edge.launchpad.net/~bilalakhtar/ubuntu/maverick/gnome-disk-utility/fix-414107/+merge/32966
[09:53] <bilalakhtar> bug #414107 bdrung
[09:54] <bilalakhtar> its a branch merge, hence bug is in-progress
[09:54] <bdrung> bilalakhtar: if your branch is ready, unassign yourself
[09:54] <bilalakhtar> bdrung: and, status of bug?
[09:55] <bdrung> bilalakhtar: sponsor don't care about the status
[09:56] <bdrung> bilalakhtar: i saw statuses of (new, confirmed, triaged, in progress, fix committed)
[09:56] <bilalakhtar> huh?
[09:56] <bilalakhtar> bdrung: what does that mean?
[09:57] <bilalakhtar> bdrung: I don;t need to subscribe sponsors to the bug, right?
[09:58] <bdrung> bilalakhtar: the merge request will appear on the sponsors list. so no need to subsrcribe the team.
[09:58] <bilalakhtar> bdrung: what do you mean by 'I saw statuses of .....'
[10:00] <bilalakhtar> ah well leave it. I know bdrung is busy. Bye!
[10:01] <bdrung> bilalakhtar: the bugs that i sponsored had a status of one of the mentioned above. we have no rule which status the bug should have.
[10:02] <bilalakhtar> aha bdrung thanks
[10:03] <bdrung> bilalakhtar: it could be everything except a 'fixed' status or Incomplete
[10:03] <bilalakhtar> thanks bdrung
[10:06] <bilalakhtar> bdrung: I just ran update-maintainer over it, so if you have already downloaded the branch, please pul
[10:06] <bilalakhtar> *pull
[10:07] <bdrung> bilalakhtar: i haven't pulled it yet. sponsor-patch will run update-maintainer (and therefore catch those mistakes) ;)
[10:07] <bilalakhtar> thanks bdrung :)
[10:42] <ricotz> seb128, hello
[10:42] <seb128> hi ricotz
[10:42] <ricotz> seb128, looks like i have a working gtk+3 package :)
[10:43] <seb128> ricotz, can you talk about it on #debian-gnome?
[10:43] <ricotz> ok
[10:43] <seb128> ricotz, ideally we would get it in debian, they started work there
[11:17] <theclaw> hi
[11:18] <theclaw> how do I have to mark config files so that when installing the package, I will get asked whether I want to overwrite the config?
[11:19] <theclaw> I already tried putting the configs in 'conffiles'
[11:21] <cjwatson> just install them somewhere under /etc, and use debhelper compat level 3 or above (usually 7 these days)
[11:21] <cjwatson> with even remotely modern debhelper you don't need to fiddle with conffiles by hand
[11:21] <cjwatson> it will only prompt you if there are some local changes versus the distributed copy
[11:22] <theclaw> yes, I have local changes. Maybe I'm using an outdated debhelper
[11:22] <cjwatson> astonishingly unlikely
[11:23] <cjwatson> well, you might be using an outdated debhelper compat level
[11:23] <theclaw> cjwatson: I have '5' in debian/compat, so this shouldn't be the problem?
[11:23] <cjwatson> but debhelper 3 dates back to 2001
[11:23] <cjwatson> then there is something else wrong and we would need detailed information (e.g. an example) to debug it
[11:23] <seb128> hum, "vesamenu.c32: not a COM32R image"
[11:24] <seb128> I wonder what went wrong with that lucid usb stick I just did
[11:24] <cjwatson> the installed version of syslinux tends to need to match
[11:24] <theclaw> cjwatson: I can't distribute anything of the package, sorry
[11:24] <seb128> cjwatson, you mean I can't do a lucid usb key with maverick usb creator?
[11:25] <theclaw> cjwatson: but thanks for the hints
[11:25] <seb128> or on maverick rather
[11:25] <cjwatson> seb128: only if you downgrade to lucid's syslinux
[11:25] <cjwatson> (at the moment)
[11:25] <seb128> cjwatson, ok thanks
[11:25] <cjwatson> theclaw: can't help if you can't share
[11:25] <seb128> I did the keys 3 times and rsync the iso again to be sure
[11:25] <seb128> it's a non obvious issue ;-)
[11:25] <cjwatson> there's an open bug for it
[11:26] <cjwatson> ev and I have talked about it, but it's mostly been conference/holiday season since then
[11:26] <seb128> ok, thanks
[11:26] <seb128> at least I know what's going on now ;-)
[11:27] <cjwatson> I'm not sure what the right answer is given that syslinux isn't actually on the CD, only isolinux
[11:42] <bilalakhtar> bdrung: I actually need to get it SRUed into Lucid at the same time. How to do this with a branch? since lp:ubuntu/lucid-proposed/gnome-disk-utility does not exist.
[11:46] <tumbleweed> bilalakhtar: propose merging into lucid instead of lucid-proposed?
[11:47] <bilalakhtar> tumbleweed: is that acceptable?
[11:47] <bilalakhtar> tumbleweed: ok, I will follow the good-old debdiff method
[11:47] <tumbleweed> other people seem to do that, the problem is that the merge request will never be marked Merged automatically...
[11:48] <tumbleweed> (and the reviewer can't mark it merged / WIP)
[11:48] <bilalakhtar> tumbleweed: well, since it is my first SRU, I don;t want to experiment with it
[11:48] <bilalakhtar> so I am debdiffing
[11:48] <tumbleweed> bilalakhtar: :)
[11:55] <bilalakhtar> tumbleweed: if you are free, bug #619738
[11:56] <bilalakhtar> tumbleweed: you were the one who got the ubuntu patches there
[11:56] <tumbleweed> bilalakhtar: hah, sure
[11:57] <geser> bilalakhtar: what's the benefit of syncing it now?
[11:57] <bilalakhtar> geser: why?
[11:57] <tumbleweed> bilalakhtar: that wasn't an ubuntu patch
[11:57] <bilalakhtar> geser: so that in N release they get synced automatically
[11:57] <bilalakhtar> tumbleweed: I know, but the reason is the same
[11:58] <bilalakhtar> geser: people say: Drop the ubuntu changes whenever possible
[11:58] <bilalakhtar> tumbleweed: the current ubuntu changes and the debian accepted changes are somewhat different, but they have the same goal: move away from python2.5
[11:59] <geser> bilalakhtar: yes, but we are currently past FF and should start focusing towards release. That also excludes syncs which no benefit right now.
[12:00] <bilalakhtar> geser: ok, I will take care about it next time onwards.
[12:01] <geser> being able to autosync for N isn't IMHO a valid reason for syncing (at least if it's the only reason)
[12:02] <bilalakhtar> geser: ah, ok, please allow this one, I will take care from the next time onwards
[12:07] <geser> bilalakhtar: sure (it's up to your sponsors to ACK it or not) but please consider if syncing a package gains us anything for the release for next syncs/merges
[12:07] <geser> we shouldn't sync/merge because we can
[12:07] <bilalakhtar> ok, I will take care from the next time onwards, geser
[12:08] <cjwatson> geser++
[12:48] <sabdfl> seb128: did you get a chance to look into gnome-terminal tabs?
[12:50] <seb128> sabdfl, not yet, still busy with feature freeze exception from dx and other teams
[12:52] <sabdfl> okdokey
[12:52] <sabdfl> i saw the version bump this morning and got all hopeful ;-)
[12:54] <seb128> sabdfl, no, that was just standard GNOME 2.31 update ;-)
[13:53] <pitti> slangasek, robbiew: \o/ 10.04.1
[13:54] <ricotz> jcastro, hello
[13:55] <pitti> robbiew: hm, https://wiki.ubuntu.com/LucidLynx/ReleaseNotes/ChangeSummary/10.04.1 looks a bit thin?
[13:56] <pitti> is there a non-boilerplate version of this?
[14:16] <cjwatson> pitti: we were stuck on a silly UTF-8 decoding error in the script that generates it - I gave a fixed version to robbiew a couple of hours ago, so he should be able to fill that out once he's up
[14:16] <cjwatson> the error was ultimately down to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593442, if you care ...
[14:17] <pitti> cjwatson: oh nice, it's autogenerated now?
[14:18] <cjwatson> pitti: more or less always was partially; it requires manual editing to do categorisation and get it into a consistent editorial voice
[14:34] <\sh> cjwatson: I just stumbled upon a bug discussion for openssh + the ldap patch...do you still support your argument, or would it be a good idea to re-check the quality of the openssh LPK  patch (bts: #319244)
[14:34] <cjwatson> I still support my argument - get it upstream first, I'm not going to carry it in a distro
[14:34] <cjwatson> sorry
[14:35] <cjwatson> I haven't made any argument either way about the quality of the patch, so that is a red herring
[14:36] <\sh> cjwatson: I just trying to find now any reference from upstream about this issue...but looks like I'm too tired to read all google hits
[14:38] <\sh> ah there
[14:41] <pitti> hm, we recently started to pull in openjdk into the images, leading to massive oversizedness
[14:44] <ahasenack> pitti: hi, is 10.04.1 out yet?
[14:44] <pitti> ahasenack: yes
[14:44] <ahasenack> pitti: cool, so -proposed is unfrozen?
[14:45] <pitti> ahasenack: right; I'll get to SRUs ASAP
[14:45] <ahasenack> pitti: thanks
[14:46] <\sh> cjwatson: when you are interested in this topic: http://marc.info/?l=openssh-unix-dev&m=127607159208207&w=2 -> the whole thread :)
[14:51] <jcastro> ricotz: hi
[14:52] <ricotz> jcastro, hi, how is the progress with the gome3 (gnome-shell) ppa?
[15:01] <jcastro> ricotz: I am not sure, I've been gone for a bit, seb128 might know
[15:01] <ricotz> jcastro, there are still plans to provide a ppa with a gnome3 preview?
[15:02] <ricotz> jcastro, ah, ok, then i am up2date
[15:02] <seb128> ricotz, not really
[15:02] <seb128> ricotz, we need to get gtk3 in with all those libraries changes first but everybody is busy
[15:03] <ricotz> seb128, ok
[15:03] <seb128> with GNOME3 delayed from one cycle and gtk3 delayed until end of year we almost have extra time
[15:04] <ricotz> seb128, ok, but the goal is still to get gtk3 into maverick?
[15:04] <seb128> would be nice to get it in universe yes
[15:05] <ricotz> my package still has some file collisions with gtk2, i am not sure about the right way to solve them
[15:06] <ricotz> but gnome-shell can be built again with it
[15:06] <cjwatson> \sh: thanks.  they seem to be going about things the right way, at last; there is probably some hope
[15:09] <robbiew> pitti: fyi, starting on the change summary now...assuming python holds up :)
[15:12] <pitti_> ahasenack: I followed up to bug 610744, there's still some bug cleanup to do
[15:13] <seb128> ricotz, I would appreciate if you didn't have your own gtk3 version in a ppa
[15:13] <seb128> ricotz, it has potential to create trouble for users who want to try it and don't know it might conflict with the official builds when we will have those
[15:14] <ricotz> seb128, yes, that is why i want someone of you to review it
[15:15] <ricotz> i still have it in my staging ppa which shouldnt be used
[15:21] <free> pitti_: hey, didn't we agree on opening SRU tasks only for the main SRU bug (which references the other ones)? for sake of convenience
[15:22] <pitti> free: we did? I can't remember
[15:22] <free> pitti: also I think that internally we were marking bugs as "Fix released" only when the packages actually hit -updates
[15:22] <pitti> free: but anyway, if the 1.5.4 changelog claims to fix a bug which is still open upstream and targetted at 1.5.5, there's something wrong?
[15:22] <pitti> free: that's what the Ubuntu task should be for then
[15:22] <pitti> free: but ok, I can accept the "fix committed" upstream state, even if it's slightly weird
[15:23] <free> pitti: right, I'm fine whatever, I just didn't open tasks because of the above
[15:23] <pitti> ok, I can't remember the discussion where we agreed to not add SRU tasks
[15:25] <free> pitti: about the wrong milestone, sorry about that, the bug should have been marked "Fix committed" quite a bit ago, but we forgot, so it was automatically shifted to 1.5.5 by a script we use at the end of the milestone
[15:25] <free> pitti: so do you prefer to have tasks for all bugs or only for the main one?
[15:25] <ScottK> Is http://people.canonical.com/~ubuntu-archive/NBS/ updating correctly?  I uploaded most of the rebuild targets for http://people.canonical.com/~ubuntu-archive/NBS/libkrb5-25-heimdal last night and even the ones that built ~12 hours ago still show there.
[15:25] <pitti> ScottK: hm, usually it does
[15:26] <pitti> cronjob is working, anyway, but only every 8 hours
[15:26]  * ScottK checks another one.
[15:27] <ScottK> pitti: Probably just got caught in the window where we don't get a publisher run for a few hours + the 8 hour cron job cycle.
[15:27] <ScottK> I'll check it again tonight then.
[15:27] <ScottK> Thanks for looking.
[15:27] <pitti> np; I have used it a few days ago, and it was working fine
[15:28] <pitti> but please let me know if the next update (at 1900 UTC) is still bad
[15:28] <ScottK> Will do.
[15:40] <cjwatson> slangasek: could you review https://code.launchpad.net/~csurbhi/ubuntu/maverick/samba/samba-fix.276472/+merge/32753 ?
[15:50] <slangasek> cjwatson: my review is not worth much there; it looks syntactically correct, but should be reviewed by somebody who understands the protocol better
[15:50] <slangasek> (i.e., upstream)
[15:51] <slangasek> cjwatson: (do you want me to follow up with an actual merge review saying this?)
[16:04] <cjwatson> slangasek: sure, just looking for somebody to claim it really
[16:53] <cnd> Hi all, are MIR reports processed on a set schedule?
[16:53] <cnd> seb128, pitti ^^?
[16:53] <pitti> cnd: not sure, asac is driving it these days
[16:53] <pitti> but I expect not
[16:54] <cnd> asac, in case you missed my question due to your ping timeout :), are MIR reports processed on a set schedule?
[17:19] <bilalakhtar> Can anyone accept the nominations at bug #414107 ?
[17:23] <achiang> slangasek: this bug has a patch and looks like Keybuk even reviewed it; any chance of taking a look? https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/537133
[17:57] <bilalakhtar> bdrung: about the bug I told you, there is an SRU also needed for it, so when you look at the maverick branch, could you please look at the debdiff attached to the bug report also (sponsors subscribed there)? That debdiff is for getting the package into lucid-proposed
[18:11] <jibel> cjwatson, hello, bug 619135, do you think that's really a packaging issue or dpkg becoming suddenly overly verbose due to the changes in <IP_ADDRESS> ?
[18:11] <jibel> cjwatson, the relevant changelog entry "* Always print a massage on warning when parsing control files."
[18:39] <akheron> I did do-release-upgrade on a karmic server today, everything was fine until libc-i686 was upgraded
[18:40] <akheron> right after that everything started to fail, failing about missing version GLIBC_2.11
[18:41] <akheron> *complaining
[18:41] <akheron> what could be wrong?
[18:42] <penguin42> akheron: Can you get an ldd /bin/ls out of it?
[18:42] <akheron> I can reproduce this easily, as I have a backup disk image of the server
[18:42] <akheron> penguin42: after the upgrade has failed?
[18:43] <penguin42> akheron: Yeh depending just how failed it is
[18:43] <akheron> I don't think so, as at least ls just segfaults
[18:43] <sebner> JontheEchidna: hola :) , if you are bored you could update k3b and make another backport maybe? :)
[18:43] <akheron> I cannot access the machine right now, and before trying again I would have to restore the backups
[18:55] <djzn> ScottK: Just dropped by to say THANK YOU for the point release
[18:56] <ScottK> djzn: It was very little to do with me, but you're welcome.  You left just slightly too soon last night.
[18:56] <djzn> yeah, i had to sleep, but doesn't matter now, it's there...
[19:18] <JontheEchidna> sebner: ooh, turns out I can merge from debian. :)
[19:21] <highvoltage> JontheEchidna: nice :)
[19:45] <SpamapS> pitti: Don't know if you noticed, but I proposed merging a change to the WI tracker that will allow you to stop regenerating all the html/burndown/json for closed out milestones.
[19:45] <SpamapS> pitti: and currently looking at speeding up the select statements a lot
[20:18] <mycae> Hello. I think I was asked in a bug to request an FFE for a  package sync (minor package that was new to debian), but I cannot seem to find any documentation on how one does this. In fact, i thought this was what I was doing. Does anyone know what I am supposed to do? (bug #617787)
[20:21] <micahg> mycae: looks like you're fine on this
[20:21] <micahg> archive admins are subscribed and FFe was approved
[20:21] <mycae> ok. good. was not clear if I had to "get" an FFE from someone/where
[20:22] <mycae> thankyou.
[21:05] <maco> i just got an email from lp saying a package i uploaded failed to build on itanic but the FAILEDTOBUILD.txt.gz says "Built  successfully" partway down...
[21:05] <maco> like, right at that end bit before the chroot cleans up and uninstalls all the stuff it installed as build deps
[21:06] <maco> i am confused by this definition of fail
[21:06] <SpamapS> maco: it detected that ia64 was a failure and noted it for you.
[21:07] <SpamapS> they've added fuzzy logic now.. if processor_architecture.value == 0: send fail email
[21:08] <SpamapS> ia: can you paste a link to the build?
[21:09] <maco> http://launchpadlibrarian.net/53949323/buildlog_ubuntu-lucid-ia64.skyeye_1.2.5-2ubuntu<IP_ADDRESS>_FAILEDTOBUILD.txt.gz
[21:18] <geser> maco: the failure is "Function `get_sym' implicitly converted to pointer at utils/main/skyeye.c:200
[21:18] <geser> "
[21:18] <geser> the source file is missing the prototype for the function
[21:19] <maco> why is that so far after the "build successful" message?
[21:19] <geser> the buildd scans the output for this and fails if it's found
[21:19] <maco> and that's a bit odd
[21:19] <geser> amd64 should fail the same way
[21:19] <maco> since its a no-change rebuild
[21:20] <maco> and the package it didnt change from /did/ build on ia64
[21:20] <geser> but a lib might have changed between the time it got build last and now
[21:21] <maco> well i dont know about ia64, but amd64 does not fail in pbuilder
[21:22] <maco> ...and actually on lp it did complete on amd64
[21:22] <maco> hmm ...
[21:22]  * maco goes back to calling it itanic
[21:22] <geser> yeah, hmm
[21:23] <geser> perhaps a header which doesn't get included on ia64 for some reason
[21:23] <maco> im glad amd64 won the 64bit market
[21:25] <ScottK> maco: You can ignore ia64 anyway, it's about to be killed.
[21:25] <ajmitch> the TB have spoken
[21:25] <ScottK> Yep.
[21:26]  * ScottK isn't sure why ia64 went along with sparc since it was still functional, but oh well.
[21:26] <maco> which was still functional?
[21:26] <ajmitch> I think it wa sfunctional but noone was caring for it
[21:26] <ScottK> ia64
[21:26] <ajmitch> but it at least booted afaik
[21:26]  * ScottK saw ia64 specific bugs reported by users as recently as Karmic.
[21:27] <ScottK> So I think it even has a non-zero number of users.
[21:27] <maco> im surprised by that
[21:27] <ScottK> But it's decided now anyway.
[21:27] <maco> do they even sell itanium hardware anymore?
[21:27] <maco> i saw it for like 6 months then people realised they couldnt use 32bit windows on it, then it went away
[21:27] <achiang> hp sells quite a bit of ia64
[21:28] <maco> is that servers?
[21:28] <achiang> it only makes $10B / year for them
[21:28] <ScottK> Yes
[21:28] <maco> ah
[21:28] <achiang> actually, that number seems wrong, please ignore it
[21:28]  * ScottK has a server running Hardy that has a motherboard/CPU that dates from 1999.
[21:28] <mdke> slangasek: around?
[21:29] <ajmitch> perhaps the port can be revived if someone steps up to look after it
[21:29]  * ScottK has another running Lucid from 2000.
[21:29] <ScottK> Perhaps, but restarting a port is hard.  Ask lamont about restarting hppa.
[21:29]  * maco would use debian if the year starts with a 1
[21:29] <penguin42> there are probably quite a few Ia64 workstations/small servers that geeks have managed to hang on to when the places they work were about to throw them out
[21:30] <ScottK> Since it's in Lucid, they'll be able to do it for another 3 - 5 years.
[21:30] <penguin42> or actually after they through them out :-)
[21:31] <ScottK> The last Sparc installer that worked was Gutsy.  The last working system was, I think, Jaunty.  So it's in a very different situation.
[21:32] <ajmitch> maco: what's wrong with using debian? :)
[21:32] <ajmitch> penguin42: especially if they have shares in power companies
[21:32] <maco> ajmitch: it's more about what's wrong with using ubuntu
[21:32] <penguin42> ajmitch: They make great heaters
[21:33] <ajmitch> maco: if you have an ia64, the answer would be obvious :)
[21:33] <maco> ajmitch: i was referring to ScottK's old machines
[21:33] <maco> i tried feisty on a c1998 machine. that was...on the edge of bearable
[21:34] <ajmitch> I had breezy on an old laptop with 128MB of RAM
[21:34] <maco> i doubt it could boot lucid..if i could find it
[21:34] <ajmitch> it was interesting
[21:35] <maco> etch + e17 was the fanciest thing i could run on it and still have enough ram available to run 1 app at a time
[21:35] <ScottK> Up through Hardy I have a laptop with 256MB of RAM I ran Kubuntu on (and even built packages)
[21:35] <ScottK> have/had
[21:35]  * ajmitch would just like little things like suspend/resume to work on hardware from last year, let alone having an ancient laptop boot
[21:35] <maco> (er, ram+swap)
[21:35] <maco> ajmitch: ancient things are more likely to work i think
[21:36] <maco> nice old stable drivers
[21:36] <ajmitch> rather than using things like fglrx
[21:36] <maco> if it predates this wifi and bluetooth dohickeys, itll probably be happy :P
[21:36] <maco> ScottK: did you have to install your own ethernet cards on those machines, or did they come with them?
[21:37] <ScottK> One came with the other is home built, so I had to add it.
[21:38] <ScottK> The laptop needed a PCMCIA ethernet card.
[21:38] <ScottK> Err wifi card.
[21:38] <ScottK> Ethernet was built in.
[21:38] <maco> i think the WinME machine was the first we had that could do ethernet
[21:52] <cjwatson> jibel: I think it might be dpkg breakage - I noticed it myself on different packages, but at the time put it down to the fact that I only restored this system from backup recently
[23:57] <jdong> hmmmmm
[23:57] <jdong> any way to debug when APT tells me "Hash Sum Mismatch" but I don't believe it?
[23:57] <jdong> the Release file's md5sum and sha1sum listed for a Packages.bz2 matches what I get when I manually fetch the URL
[23:59] <penguin42> jdong: I've seen that type of thing happen with dodgy ram or other faults


[07:46] <Bebef> I'm trying to re-install my server with 22.04 LTS. Unfortunately, as soon as I start the installer (from the GRUB menu), all I end up is a black screen, regardless of using the "normal" or HWE menu entry. I already tested different cables and monitors, it's not that. Any hints on how to get the installer to run?
[07:47] <Bebef> I have LAN, so something ssh based would be feasible.
[13:34] <Niclos98> Hello all,
[14:19] <Niclos98> I tried to join the second Domain for Ubuntu 22.04  and its not able to  the second domain there some  details, if anyone can help thank you.
[14:19] <Niclos98> # vi /etc/krb5.conf
[14:19] <Niclos98> #[libdefaults]
[14:19] <Niclos98> #udp_preference_limit = 0
[14:19] <Niclos98> #default_realm = DOMAIN1.COM
[14:19] <Niclos98> [domain_realm]
[14:19] <Niclos98> .domain1.com = DOMAIN1.COM
[14:19] <Niclos98> domain1.com = DOMAIN1.COM
[14:19] <Niclos98> .domain2.com = DOMAIN2.COM
[14:19] <Niclos98> domain2.com = DOMAIN2.COM
[14:19] <Niclos98> -->save and exit
[14:19] <Niclos98> and then run this command to join the domain2.com
[14:19] <Niclos98> # adcli join --host-keytab=/etc/krb5.keytab.domain2.com domain2.com
[14:19] <Niclos98> Password for<EMAIL_ADDRESS>[14:19] <Niclos98> adcli: couldn't connect to domain2.com domain: Couldn't authenticate as<EMAIL_ADDRESS>Client<EMAIL_ADDRESS>not found in Kerberos database
[14:58] <teward> !paste | Niclos98
[14:58] <teward> just for future reference.
[15:00] <Niclos98> teward: okay, I will.


[17:04] <yofel> so, after having been ~kubuntu-dev for a few years and getting to know the distro pretty well, what would be the appropriate way to apply for ~motu permissions? Any particular prerequisites i should be respecting?
[17:06] <mitya57> yofel, the usual way: https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[17:06] <yofel> mitya57: thanks
[17:07] <mitya57> It would be really nice to have you in MOTUs!


[06:30] <robert_ancell> RAOF, Can Xephyr be run in rootless mode?
[06:30] <RAOF> robert_ancell: I don't believe so, but could probably be made to do so easily.
[06:31] <robert_ancell> RAOF, define "easily" :)
[06:31] <RAOF> robert_ancell: Well, you'd get most of the way there by having a root window and just making it transparent? :)
[06:32] <robert_ancell> RAOF, but then the window decorations would get very complicated for the internal WM
[06:32] <RAOF> Yeah, is true.
[06:33] <RAOF> So, my guess is “not *terribly* difficult or invasive”.
[06:33] <RAOF> Well, maybe a *bit* invasive.
[06:34] <RAOF> Say, less than a month all up?
[06:35] <robert_ancell> For who? I think it would be more than that for me given my experience. Perhaps a RAOF+duflu team would do it in a month..
[06:36] <robert_ancell> RAOF, with XMir in rootless mode, how much work does the window manager need to do? The placement should all be done by the parent WM right?
[06:36] <robert_ancell> I mean the WM that runs inside XMir
[06:36] <RAOF> Yeah.
[06:37] <RAOF> The end-state for XMir in rootless mode is that the X11-WM is basically nothing but a proxy to the external WM.
[06:37] <RAOF> Needs to do a bit of translation for resizing and such.
[06:38] <duflu> robert_ancell: Xmir -rootless completely throws away the window manager, and implements WM itself Mir-style
[06:39] <robert_ancell> duflu, ah
[06:39] <duflu> You could still run one, but it might conflict
[06:39] <robert_ancell> So XMir on X would probably be the most working solution...
[06:39] <duflu> robert_ancell: On X?
[06:40] <robert_ancell> Mir has an X backend right?
[06:40] <robert_ancell> (I'm kidding)
[06:40] <duflu> robert_ancell: Yes it does exist, but that's fullscreen Mir server in an X window
[06:42] <duflu> robert_ancell: Xmir -rootless implements its own XComposite-based window management. I know of no shell that handles it well yet, but also implemented a workaround for that too: Xmir -rootless -flatten  which only asks the Mir shell to implement one window per app (which most Mir shells can handle)
[06:43] <duflu> Umm, I mean -flatten uses XComposite
[06:44] <duflu> So Xmir uses Xorg to do the compositing in software with -rootless -flatten
[06:44] <duflu> Actually since widgets are windows, that's normal
[06:53] <RAOF> It's not using the hardware-accelerated compositing path?
[06:54] <duflu> Nope. Because that's actually very buggy, and not beneficial to pursue right now either
[06:55] <RAOF> That seems unlikely? We're using the same glamor hardware-composited path on regular X.
[06:55] <duflu> RAOF: armhf is set to always software anyway. Desktop is not
[06:56] <duflu> That's why it works
[06:56] <RAOF> That I can see; armhf glamor is unlikely to be awesomely well tested :)
[07:00] <duflu> Hardware acceleration matters much more for GLX clients. However that's only really feasible with DRI (desktop hardware)
[07:00] <duflu> And in all fairness, even software buffers are cached in hardware for most of their life, so performance is good
[07:04] <RAOF> Right, but GPU composition is vastly faster than CPU composition on all hardware.
[07:04] <RAOF> If you're actually *doing* any composition...
[07:06] <duflu> RAOF: True, but "vastly" is still completely insignificant compared to even a single frame of lag. And we have several frames of lag.
[07:06] <duflu> So that gets attention first
[07:07] <RAOF> I don't think that's the case?
[07:07] <RAOF> As evidenced by your discovery that your monitor introduces a 20ms delay that you were entirely unaware of.
[07:07] <duflu> It is. Proof: Software rendering completes in well under 16ms even on mobile. Our buffering lag is closer to 90ms
[07:08] <RAOF> But that's two different types of milliseconds :)
[07:08] <duflu> RAOF: In user perception
[07:09] <RAOF> But as long as rendering *is* maintaining 60Hz, lag is indeed a more interesting target.
[07:09] <duflu> It is. Software rendering is very fast even on a phone (with the exception of the infamous OTA-10 regression)
[07:10] <RAOF> Right. User perception is “30Hz is worse than a consistent 90ms of lag, even though frames containing my input reach the screen faster”.
[07:11] <duflu> RAOF: Agreed, but that's not an issue. Also it would be irresponsible to pursue. Do you want Xmir working in 2015 as it was, or wait till 2017/2018?
[07:11] <RAOF> Yeah, I'm agreeing with you.
[07:11] <RAOF> As long as we're hitting frame deadlines, we don't *really* need to increase rendering performance.
[07:13] <duflu> RAOF: Even still, less important than our other current performance focal points
[07:14] <duflu> No one cares if you've made Xmir faster if you had to stop working on improving the performance of all of Unity8
[07:32] <zzarr> hello! does Mir software rendering work now?
[07:34] <duflu> zzarr: In very very limited conditions. Depends what you're trying to do
[07:34] <duflu> But mostly not
[07:35] <zzarr> duflu, I'm not trying to do anything right now, it was just a general question
[07:36] <duflu> We are making baby steps in other tasks that will help generic software rendering in future
[07:37] <zzarr> nice
[07:48] <zzarr> of course I still want to try to get Ubuntu with Mir running om my chromebook
[07:49] <zzarr> it's vital that I can turn both the touch pad and keyboard off when flipping it
[07:50] <zzarr> (ti's an Asus Chromebook Flip)
[07:50] <zzarr> it's*
[07:51] <anpok> so you want them to be gone.. so that unity8 discovers that there are not more desktop input device, so it would switch to the tablet ui?
[07:52] <zzarr> anpok, exactly
[07:59] <duflu> Do we need to test of integer wraparounds that will happen after the Sun engulfs the Earth?
[07:59] <duflu> I guess we should assume Mir is running outside the solar system
[08:01] <anpok> zzarr: hm we should have the necessary interfaces in mir
[08:02] <anpok> zzarr: but you would need changes to unity-system-compositor to deal with that... detect the lid switch telling you the flip state?.. hm.
[08:02] <zzarr> anpok, nice
[08:02] <zzarr> anpok, I don't know
[08:03] <anpok> sounds like hwdb in usc .. dmidecode.. have lots of rules for various devices..
[08:04] <anpok> oh i believe we do not expose the input device registy in the mir server api... but thats the smallest problem
[08:04] <anpok> i thought about another interface to allow the compositor to filter out input devices..
[08:04] <zzarr> anpok, okey, sadly I don't know anything about that, I just have a vision that I one day can run Ubuntu/Mir on my laptop
[08:06] <zzarr> well, a script telling mir/unity that it should enter tablet mode and one that tells it to enter desktop mode would be nice
[08:07] <zzarr> are the input filtered or are they turned off? (hw)
[08:07] <anpok> hm ... if you would tell an InputDevice to stop libinput would still read from evdev
[08:08] <anpok> but thats an implementation detail.. because we use libinputs udev handling.. and turning it off and on again would require to retrigger scanning udev devices..
[08:09] <anpok> the reason for using that are also further implementation details in libinput itself .. because of historic reasons it does certain init steps only when you let it handle udev..
[08:10] <zzarr> I'm feeling I'm on thin ice... never mind you answered the question before I asked it
[08:10] <anpok> is it important that evdev events are not consumed?
[08:10] <anpok> believe me there is no ice
[08:12] <zzarr> anpok, does evdev events trigger text on the screen? (keyboard inputs)
[08:13] <anpok> well input events take a route through the system compositor down to the focused client i noone filters it along that line.. and the rendered results comes back to screen
[08:13] <anpok> *if no one filters it
[08:20] <zzarr> okey, in that case, yes it is important that it's filtered (the keyboard/mouse pad ends up on the backside when flipped)
[08:20] <anpok> oh
[08:20] <anpok> I thought the screen is rotated then closed
[08:26] <zzarr> this image shows the form factor http://liliputing.com/wp-content/uploads/2015/03/asus-chromebook-flip_02.jpg
[08:38] <robert_ancell> duflu, RAOF, I figure it's about time to propose XMir upstream. Any opposition?
[08:38] <duflu> robert_ancell: Ha. I would not have except just landed an emergency fix from Chris Townsend today. Not sure how to test it
[08:39] <robert_ancell> duflu, I expect upstream is not going to test it in any detail anyway, so shouldn't be a problem.
[08:39] <duflu> Upstream would need Mir to complain about anything. So long as we don't break code outside our own dir
[08:40] <robert_ancell> Exactly. And it seems to be in well self contained now
[09:06]  * duflu is guessing there are lots of desktoppers in London
[09:06] <robert_ancell> Prague
[09:06] <duflu> Close
[09:06] <duflu> Closer than here
[09:06] <robert_ancell> Yep
[09:06] <duflu> robert_ancell: What venue?
[09:06] <robert_ancell> Hotel
[09:07] <duflu> robert_ancell: Erm, which?
[09:07] <robert_ancell> https://www.google.cz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjHiY7S_bDMAhVqAZoKHXi5DiYQFggdMAA&url=http%3A%2F%2Fprague.boscolohotels.com%2F&usg=AFQjCNGa9EmXsm9WPTU0TKXUdwLjaNbSvQ
[09:07] <robert_ancell> ah, stupid google links
[09:07] <robert_ancell> http://prague.boscolohotels.com/
[11:14] <alan_g> attente: I'm working through the window management issues in Mir. It looks like gtk-mir might the cause of lp:1445543 - I've updated the description with a specific case that seems to show Mir passing events to the client that are ignored, can you check what happens in gtk?
[11:19] <attente> alan_g: hey, sorry. i got your message, but didn't have a chance to check yet
[11:20] <alan_g> attente: np
[11:45] <bregma> hey robert_ancell I was going to ask if there was any reason (like maybe an Intel incident) why we haven't upstreamed XMir...  I guess my question has been answered
[11:46] <bregma> are you willing to do the work?
[11:46] <robert_ancell> bregma, yep
[11:47] <bregma> great
[11:50] <anpok_> bregma: looked at our xkb mapping code..
[11:51] <anpok_> the altGr problem could be caused by other problems
[11:51] <robert_ancell> hmm, why can't I VT switch out of mir_demo_server anymore?
[11:51] <bregma> anpok_, problems within Mir, or elsewhere?
[11:51] <anpok_> we seem to use the api wrong..
[11:51] <anpok_> yeah mir client.. i finish up the nested stuff and verify that theory
[11:51] <alan_g> robert_ancell: it should be possible - I do it a lot
[11:52] <bregma> anpok_, OK, so still Mir but on the client library?
[11:52] <anpok_> yes
[11:52] <bregma> k
[11:52] <robert_ancell> alan_g, yeah, it used to work fine. But not working for me right now... alt+ctrl+backspace seems to quit it, but not mir_demo_server_minimal
[11:53] <alan_g> robert_ancell: minimal doesn't install the quit handler
[12:01] <robert_ancell> alan_g, is there any easy way to log the keyboard events?
[12:01] <anpok_> MIR_CLIENT_INPUT_RECEIVER_REPORT=log
[12:02] <anpok_> oh in a server?
[12:02] <robert_ancell> anpok_, yeah, the server
[12:02] <anpok_> MIR_SERVER_INPUT_REPORT does some logging.. not sure if it contais key code
[12:02] <anpok_> *contains key codes
[12:03] <robert_ancell> hmm, doesn't seem to
[12:03] <robert_ancell> I'm wondering if it doesn't work because I need to hold down 'Fn' for my F keys
[12:04] <robert_ancell> If I can get a log of keycodes that might help
[12:05] <anpok_> hm ok it does .. you should see "Received event .. type=EV_KEY code=<some number> value=0/1"
[12:06] <anpok_> when you set that env var to =log
[12:06] <robert_ancell> I got nothing when I set MIR_SERVER_INPUT_REPORT=log
[12:06] <robert_ancell> But mir_demo_server --print-input-events does something, but the output seems to overwrite so I can't read it
[12:07] <robert_ancell> http://paste.ubuntu.com/16094191/
[12:08] <robert_ancell> Should the keycode always be 0?
[12:10] <robert_ancell> The only scancodes seem to be alt, ctrl and backspace. i.e. nothing for Fn or the function keys
[12:10] <anpok_> yeah.. no scan to key code translation on the server
[12:11] <anpok_> ok thats.. odd..
[12:12] <robert_ancell> I wonder if the function keys are done with ACPI?
[12:17] <robert_ancell> showkey suggests F2 is scancode 224, which is KEY_BRIGHTNESSDOWN
[12:18] <anpok_> aeh.. hm but neither libinput nor mir filters out keys
[12:22] <anpok_> robert_ancell: what does evtest say about the input devices that you have?
[12:22] <robert_ancell> ah, KEY_F2 does work, but not in combination with alt+ctrl for some reason
[12:27] <robert_ancell> ok, now with more careful testing, I am getting the event to show with --print-input-events, but still no VT switch
[12:28] <robert_ancell> Seems the order in which I press 'Fn' matters
[12:31] <robert_ancell> ah. I know what this is. The VT switching is done on /dev/console which for some reason stopped working in Xenial. This affected LightDM, so I switched to using /dev/tty0 which is what other things use (GDM, logind).
[12:32] <robert_ancell> I'll make a merge proposal...
[14:42] <robert_ancell> anpok, https://code.launchpad.net/~robert-ancell/mir/vt-tty0/+merge/293277


[03:07] <thetrav> I've noticed my cluster controller emits a DHCP request every 3 minutes or so and then answers itself with a lease... Is this behaviour documented anywhere?
[03:13] <thetrav> like... it sends a broadcast request asking if it can have an un-used ip address, answers itself saying " yeah you can have it" then does nothing further
[03:13] <thetrav> I figured it could be some "magic find other cluster controllers" feature, or some sort of "tell me when someone else is running dhcp" feature?
[03:44] <bigjools> thetrav: it's probing for other dhcp servers on the network
[03:44] <thetrav> yep, thanks, I found the sentence
[03:44] <thetrav> it appears that it just lists them on the html page rather than doing anything about it... which is fine I suppose
[10:23] <caribou> Is there such a thing as "maas dumpdata" command ?
[10:24] <caribou> I mean, is dumpdata an option of the maas command ?


[06:37] <marco> hello?
[06:37] <rfm> hi marco
[06:37] <rfm> bye marco
[15:35] <rowboat> hi people
[15:35] <orqcxha> hi people!
[15:37] <rowboat> I'd like to ask you help. In xubuntu, is it possible somehow, to open the menu which is in the top left corner with the windows button? And secondly, is there a shortcut to minimise every window like in windows.
[15:38] <orqcxha> Open the menu? You can click the xfce logo to open it?
[15:38] <orqcxha> Ah i wish i could delete my message
[15:39] <orqcxha> I wasnt paying full attention
[15:40] <gnrp> Hm, but I am wondering: You mean the whisker menu, where you start applications and so on? Or the one with the icon of the application?
[15:41] <rowboat> the xubuntu logo
[15:42] <rowboat> white something in a blue disk
[15:42] <rowboat> I'd like to press something on the keyboard, and the get the result if I was clicking on it with the touchpad
[15:57] <orqcxha> So just to say something I'd expect the config files to be under ~/.config xfce and such but there could be some menu driven thing too if i remember well but the strange thing is that my super/windows key works just like you'd want it to
[15:57] <orqcxha> Pretty sure ive seen the hide all windows thing too at some point maybe in the bottom dock i disabled earlier
[15:58] <orqcxha> There's a panel menu option under settings I'd look there
[15:59] <orqcxha> Because that blue button is the whisker menu item on panel 0 that gnrp mentioned
[15:59] <orqcxha> It should be configurable
[15:59] <gnrp> yes, there is. But what do you mean, "is it possible to open"? Like on a shortcut?
[16:00] <gnrp> or you want it on another bar somewhere?
[16:00] <orqcxha> I think somehow their windows/super button doesnt open it
[16:01] <gnrp> rowboat: And for the second, go to Settings => Window management => Keyboard. There is an option "Hide all windows" (or so). It is by default on Alt+F9. This is what you're looking for
[16:02] <rowboat> gnrp: yes, like on a shortcut
[16:02] <rowboat> I'll dive into settings, thanks for the tip
[16:03] <gnrp> rowboat: For the first one then, go to Settings => Keyboard => Shortcuts
[16:03] <gnrp> and then create a shortcut for xfce4-popup-whiskermenu
[16:08] <gnrp> I e.g. have it on Alt+Space


[07:08] <sil2100> Laney: hey! Did you look why some of the gstreamer cosmic packages are still stuck in -proposed?
[07:08] <sil2100> I'd prefer not to release the bionic ones before the cosmic ones are in the release pocket
[07:09] <sil2100> Laney: could you make sure those migrate?
[08:02] <Laney> sil2100: I replied to you before, they are entangled with everything else in proposed
[08:10] <sil2100> Laney: thanks! (sorry for asking twice then, probably forgot/missed it when I asked the first time during the review)
[08:21] <Laney> np!
[08:31] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-24.26~16.04.1] (kernel)
[08:32] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-24.26~16.04.1]
[10:25] <ginggs> would someone please 'force-badtest pyfai/0.15.0+dfsg1-1/amd64' ?  It looks like it passed once accidentally on 2018-06-01  http://autopkgtest.ubuntu.com/packages/p/pyfai/cosmic/amd64
[11:13] -queuebot:#ubuntu-release- New binary: dgit [amd64] (cosmic-proposed/universe) [5.0] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: node-capture-stream [amd64] (cosmic-proposed/none) [0.1.2-1] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: primesieve [s390x] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: genius [s390x] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
[11:13] -queuebot:#ubuntu-release- New binary: node-matcher [amd64] (cosmic-proposed/none) [1.0.0-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: lttoolbox [amd64] (cosmic-proposed/universe) [3.4.2-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: ros-gencpp [amd64] (cosmic-proposed/universe) [0.6.0-3] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: xmedcon [amd64] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: node-resolve-cwd [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: xmedcon [i386] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: ros-genlisp [amd64] (cosmic-proposed/universe) [0.4.16-3] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: genius [i386] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: node-term-size [amd64] (cosmic-proposed/none) [1.2.0+dfsg-1] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: primesieve [arm64] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: node-quick-lru [amd64] (cosmic-proposed/none) [1.1.0-1] (no packageset)
[11:15] -queuebot:#ubuntu-release- New binary: node-uniqs [amd64] (cosmic-proposed/none) [2.0.0-1] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: genius [arm64] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: primesieve [armhf] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: more-itertools [amd64] (cosmic-proposed/universe) [4.2.0-1] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: radare2 [amd64] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
[11:18] -queuebot:#ubuntu-release- New binary: genius [amd64] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
[11:18] -queuebot:#ubuntu-release- New binary: genius [armhf] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
[11:18] -queuebot:#ubuntu-release- New binary: openhpi [s390x] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
[11:19] -queuebot:#ubuntu-release- New binary: primesieve [i386] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: radare2 [armhf] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: xmedcon [arm64] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: radare2 [arm64] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: radare2 [s390x] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
[11:20] -queuebot:#ubuntu-release- New binary: xmedcon [armhf] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: primesieve [amd64] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
[11:22] -queuebot:#ubuntu-release- New binary: xmedcon [s390x] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
[11:24] -queuebot:#ubuntu-release- New binary: openhpi [amd64] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
[11:25] -queuebot:#ubuntu-release- New binary: openhpi [ppc64el] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
[11:26] -queuebot:#ubuntu-release- New binary: uwsgi [amd64] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
[11:26] -queuebot:#ubuntu-release- New binary: uwsgi [i386] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
[11:27] -queuebot:#ubuntu-release- New binary: primesieve [ppc64el] (cosmic-proposed/universe) [7.0+ds-3] (no packageset)
[11:27] -queuebot:#ubuntu-release- New binary: uwsgi [s390x] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: genius [ppc64el] (cosmic-proposed/universe) [1.0.24-2] (no packageset)
[11:29] -queuebot:#ubuntu-release- New binary: openhpi [arm64] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
[11:29] -queuebot:#ubuntu-release- New binary: xmedcon [ppc64el] (cosmic-proposed/universe) [0.15.0+dfsg-1] (no packageset)
[11:30] -queuebot:#ubuntu-release- New: accepted dgit [amd64] (cosmic-proposed) [5.0]
[11:30] -queuebot:#ubuntu-release- New binary: openhpi [armhf] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
[11:30] -queuebot:#ubuntu-release- New binary: radare2 [ppc64el] (cosmic-proposed/universe) [2.6.0+dfsg-1] (no packageset)
[11:30] -queuebot:#ubuntu-release- New: accepted lttoolbox [amd64] (cosmic-proposed) [3.4.2-1]
[11:30] -queuebot:#ubuntu-release- New binary: openhpi [i386] (cosmic-proposed/main) [3.8.0-1] (ubuntu-server)
[11:30] -queuebot:#ubuntu-release- New: accepted more-itertools [amd64] (cosmic-proposed) [4.2.0-1]
[11:30] -queuebot:#ubuntu-release- New: accepted node-matcher [amd64] (cosmic-proposed) [1.0.0-1]
[11:30] -queuebot:#ubuntu-release- New: accepted node-resolve-cwd [amd64] (cosmic-proposed) [2.0.0-1]
[11:30] -queuebot:#ubuntu-release- New: accepted node-uniqs [amd64] (cosmic-proposed) [2.0.0-1]
[11:30] -queuebot:#ubuntu-release- New: accepted ros-genlisp [amd64] (cosmic-proposed) [0.4.16-3]
[11:30] -queuebot:#ubuntu-release- New: accepted node-capture-stream [amd64] (cosmic-proposed) [0.1.2-1]
[11:30] -queuebot:#ubuntu-release- New: accepted node-term-size [amd64] (cosmic-proposed) [1.2.0+dfsg-1]
[11:30] -queuebot:#ubuntu-release- New: accepted node-quick-lru [amd64] (cosmic-proposed) [1.1.0-1]
[11:30] -queuebot:#ubuntu-release- New: accepted ros-gencpp [amd64] (cosmic-proposed) [0.6.0-3]
[11:36] -queuebot:#ubuntu-release- New: accepted genius [amd64] (cosmic-proposed) [1.0.24-2]
[11:36] -queuebot:#ubuntu-release- New: accepted genius [armhf] (cosmic-proposed) [1.0.24-2]
[11:36] -queuebot:#ubuntu-release- New: accepted genius [ppc64el] (cosmic-proposed) [1.0.24-2]
[11:36] -queuebot:#ubuntu-release- New binary: uwsgi [armhf] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
[11:36] -queuebot:#ubuntu-release- New: accepted genius [arm64] (cosmic-proposed) [1.0.24-2]
[11:36] -queuebot:#ubuntu-release- New: accepted genius [s390x] (cosmic-proposed) [1.0.24-2]
[11:36] -queuebot:#ubuntu-release- New: accepted genius [i386] (cosmic-proposed) [1.0.24-2]
[11:37] -queuebot:#ubuntu-release- New binary: uwsgi [arm64] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
[11:37] -queuebot:#ubuntu-release- New binary: uwsgi [ppc64el] (cosmic-proposed/universe) [2.0.15-12] (no packageset)
[11:43] -queuebot:#ubuntu-release- New: accepted openhpi [amd64] (cosmic-proposed) [3.8.0-1]
[11:43] -queuebot:#ubuntu-release- New: accepted openhpi [armhf] (cosmic-proposed) [3.8.0-1]
[11:43] -queuebot:#ubuntu-release- New: accepted openhpi [ppc64el] (cosmic-proposed) [3.8.0-1]
[11:43] -queuebot:#ubuntu-release- New: accepted primesieve [amd64] (cosmic-proposed) [7.0+ds-3]
[11:43] -queuebot:#ubuntu-release- New: accepted primesieve [armhf] (cosmic-proposed) [7.0+ds-3]
[11:43] -queuebot:#ubuntu-release- New: accepted primesieve [ppc64el] (cosmic-proposed) [7.0+ds-3]
[11:43] -queuebot:#ubuntu-release- New: accepted openhpi [arm64] (cosmic-proposed) [3.8.0-1]
[11:43] -queuebot:#ubuntu-release- New: accepted openhpi [s390x] (cosmic-proposed) [3.8.0-1]
[11:43] -queuebot:#ubuntu-release- New: accepted primesieve [i386] (cosmic-proposed) [7.0+ds-3]
[11:43] -queuebot:#ubuntu-release- New: accepted openhpi [i386] (cosmic-proposed) [3.8.0-1]
[11:43] -queuebot:#ubuntu-release- New: accepted primesieve [s390x] (cosmic-proposed) [7.0+ds-3]
[11:43] -queuebot:#ubuntu-release- New: accepted primesieve [arm64] (cosmic-proposed) [7.0+ds-3]
[11:44] -queuebot:#ubuntu-release- New: accepted xmedcon [amd64] (cosmic-proposed) [0.15.0+dfsg-1]
[11:44] -queuebot:#ubuntu-release- New: accepted xmedcon [armhf] (cosmic-proposed) [0.15.0+dfsg-1]
[11:44] -queuebot:#ubuntu-release- New: accepted xmedcon [ppc64el] (cosmic-proposed) [0.15.0+dfsg-1]
[11:44] -queuebot:#ubuntu-release- New: accepted xmedcon [arm64] (cosmic-proposed) [0.15.0+dfsg-1]
[11:44] -queuebot:#ubuntu-release- New: accepted xmedcon [s390x] (cosmic-proposed) [0.15.0+dfsg-1]
[11:44] -queuebot:#ubuntu-release- New: accepted xmedcon [i386] (cosmic-proposed) [0.15.0+dfsg-1]
[11:48] -queuebot:#ubuntu-release- New: accepted uwsgi [arm64] (cosmic-proposed) [2.0.15-12]
[11:48] -queuebot:#ubuntu-release- New: accepted uwsgi [ppc64el] (cosmic-proposed) [2.0.15-12]
[11:49] -queuebot:#ubuntu-release- New: accepted uwsgi [amd64] (cosmic-proposed) [2.0.15-12]
[11:49] -queuebot:#ubuntu-release- New: accepted uwsgi [i386] (cosmic-proposed) [2.0.15-12]
[11:49] -queuebot:#ubuntu-release- New: accepted uwsgi [armhf] (cosmic-proposed) [2.0.15-12]
[11:49] -queuebot:#ubuntu-release- New: accepted uwsgi [s390x] (cosmic-proposed) [2.0.15-12]
[11:55] -queuebot:#ubuntu-release- New binary: datalad [amd64] (cosmic-proposed/universe) [0.10.1-1] (no packageset)
[12:26] <doko> apw: please could you have a look at the linux autopkg test failures triggered by gcc?  or tell me who could do that
[12:41] -queuebot:#ubuntu-release- Unapproved: gnome-control-center (bionic-proposed/main) [1:3.28.1-0ubuntu<IP_ADDRESS> => 1:3.28.1-0ubuntu<IP_ADDRESS>] (ubuntu-desktop)
[12:55] <apw> doko, yep, will figure out someone
[13:27] <stgraber> could someone look at lxcfs in bionic-proposed? it's a minor fix (debian/rules) on top of the current SRU to fix an upgrade regression
[14:15] -queuebot:#ubuntu-release- Unapproved: update-notifier (bionic-proposed/main) [3.192.1 => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[14:16] <juliank> LocutusOfBorg: please don't break versioning for update-notifier next time. you incremented the third level (3.192.1 to 3.192.2 in cosmic) where you should have gone to 3.193
[14:16]  * juliank now named the bionic SRU <IP_ADDRESS>
[14:17] <juliank> Probably should bump cosmic to 3.193
[14:17] <juliank> But I saw no point in doing that for 3.192.{4,5} given that the versioning was broken anyway
[14:43] -queuebot:#ubuntu-release- Unapproved: maas (bionic-proposed/main) [2.4.0~beta2-6865-gec43e47e6-0ubuntu1 => 2.4.0-6981-g011e51b7a-0ubuntu1~18.04.1] (ubuntu-server)
[15:07] -queuebot:#ubuntu-release- Unapproved: update-notifier (artful-proposed/main) [3.186.2 => 3.186.3] (ubuntu-desktop, ubuntu-server)
[15:23] -queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.8 => 3.168.9] (ubuntu-desktop, ubuntu-server)
[16:00] -queuebot:#ubuntu-release- Unapproved: rfkill (xenial-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu3.1] (desktop-core)
[16:02] <LocutusOfBorg> sorry juliank !
[16:03] <LocutusOfBorg> can anybody please check rfkill?
[16:04] <rbasak> I just commented.
[16:04] <LocutusOfBorg> lovely thanks
[16:05] <rbasak> I'm not sure it's necessary to add a dependency, but feel free to tell me why I'm wrong.
[16:09] <LocutusOfBorg> I answered...
[16:09] <LocutusOfBorg> I honestly have no strong point
[16:09] <LocutusOfBorg> we added new aircrack-ng to backbox ppa and discovered this issue
[16:10] <LocutusOfBorg> since the patch you think might be trivial, can you please share it?
[16:10] <LocutusOfBorg> I would like to avoid conditionalizing the call, but you might have a smarter approach in mind I'm not aware of...
[16:10] <LocutusOfBorg> like dpkg -l ?
[16:11]  * LocutusOfBorg goes catching a train
[16:16] <rbasak> LocutusOfBorg: the common pattern is to use test -x or similar.
[16:16] <rbasak> It does involve hardcoding the expected location of udevadm
[16:16] <rbasak> Or you do it via command -v etc.
[16:17] <rbasak> command -v udevadm >/dev/null && udevadm ...
[16:18] <rbasak> LocutusOfBorg: || true is fine also I think
[16:18] <rbasak> LocutusOfBorg: all of those options are better than adding the dependency I think
[16:19] <rbasak> For fixing this particular use case at least.
[17:13] -queuebot:#ubuntu-release- New binary: ruby-encryptor [amd64] (cosmic-proposed/none) [3.0.0-2] (no packageset)
[17:15] <stgraber> infinity: can you let that follow-up lxcfs upload in (bionic-proposed, fixes regression in SRU currently in -proposed)?
[17:19] -queuebot:#ubuntu-release- Unapproved: rfkill (xenial-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu3.1] (desktop-core)
[17:23] -queuebot:#ubuntu-release- Unapproved: rfkill (xenial-proposed/main) [0.5-1ubuntu3 => 0.5-1ubuntu3.1] (desktop-core)
[17:28] <LocutusOfBorg> rbasak, I fixed up
[17:28] <LocutusOfBorg> ^^
[17:28] <LocutusOfBorg> (probably removing this postinst file is even a better fix, since this was a leftover until xenial release
[17:28] <LocutusOfBorg> but meh, somebody might still be upgrading from trusty
[18:04] -queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.1ubuntu<IP_ADDRESS>]
[18:04] -queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.2ubuntu1~18.04.0]
[18:57] <stgraber> slangasek, bdmurray: either of you around to look at that lxcfs upload? (nagging because anyone upgrading to the current one in -proposed will have all their containers crash)
[18:58] <bdmurray> stgraber: I am
[18:58] <stgraber> bdmurray: thanks!
[19:01] -queuebot:#ubuntu-release- Unapproved: accepted lxcfs [source] (bionic-proposed) [3.0.1-0ubuntu2~18.04.1]
[20:09] -queuebot:#ubuntu-release- New binary: watcher [amd64] (cosmic-proposed/universe) [1:1.8.0-5ubuntu1] (no packageset)
[22:22] -queuebot:#ubuntu-release- New binary: neutron [amd64] (cosmic-proposed/main) [2:13.0.0~b2-0ubuntu2] (openstack, ubuntu-server)
[23:49] <tsimonq2> I was thinking of doing a Qt transition at the end of this week but by the looks of -proposed that would probably be bad.
[23:50] <tsimonq2> Are there any overarching transitions I can help with? I see a lot of R stuff and a lot of Haskell stuff.


[13:41] <Laney> Might be a good idea to reject ibus/1.5.5-1ubuntu4 from trusty-proposed UNAPPROVED
[13:41] <Laney> it seems to revert the changes from the previous one, should be fixed in a different way in ^^^
[14:29] <infinity> Laney: Done.
[15:03] <Laney> infinity: ta
[15:41] <LocutusOfBorg> can anybody please look at llvm-* in wily-proposed?
[15:41] <LocutusOfBorg> trivial debdiff, fixing a build failure
[21:27] <flexiondotorg> infinity, Yo!
[21:27] <flexiondotorg> Couple of questions.
[21:27] <flexiondotorg> How is the PowerPC migration to GRUB coming along?
[21:27] <flexiondotorg> And please could you update ubuntu-mate-meta - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-meta/+bug/1535910
[21:28] <flexiondotorg> Quite a chuck of change in the above. I'm knocking about for a couple of hours on IRC if you need to check anything with me.
[23:36] <flexiondotorg> cyphermox, Any chance you're about?


[00:12] <bkerensa> yay
[00:12] <bkerensa> about page update
[01:46] <c_smith> bkerensa, which page update?
[01:46] <c_smith> :P
[01:47] <c_smith> also, E17 is nice.
[05:13] <cy1> anyone know of a program that can visualize a graph with both directed and undirected edges?
[16:53] <bkerensa> nathwill: so I guess Debian beering isactually today
[16:58]  * nathwill nods
[17:23] <bkerensa> nathwill: you going still?
[17:49] <nathwill> lolz
[18:15] <bkerensa_> nathwill: so I guess I will be going tonight
[18:15] <nathwill> :)
[18:16] <nathwill> good!
[18:17] <bkerensa_> TRAVISg: you coming tonight?
[18:17] <bkerensa_> :D
[18:17] <bkerensa_> I think it was actually znc being slow ;p
[21:37] <bkerensa_> sbeattie / bdmurray: You guys coming to beer tonight?
[21:37] <bkerensa_> or Ginger Ale :)
[21:37] <bdmurray> bkerensa_: not I
[21:38] <sbeattie> me either.
[21:38] <bkerensa> kk
[21:52] <c_smith> how's it going?
[21:53] <c_smith> anyone here mind giving me their take on my choice of replacement PC's (that will run Ubuntu)?
[21:57] <tgm4883> c_smith, only if you post it
[21:57] <c_smith> alright, let me get the links.
[21:57] <c_smith> it's a tie between http://www.newegg.com/Product/Product.aspx?Item=N82E16834246328
[21:57] <c_smith> and   http://www.newegg.com/Product/Product.aspx?Item=N82E16834246219
[21:57] <c_smith> would like input on that.
[22:04] <bkerensa> c_smith: I thought you just got a new computer? :)
[22:04] <c_smith> nope, been working on it, though.
[22:05] <c_smith> bkerensa, hopefully I can work something out for that.
[22:05] <c_smith> still working on my beat up old laptop.
[22:10] <tgm4883> I'm always a fan of more ram, and I don't know the difference between the two processors
[22:10] <c_smith> alright.
[22:10] <tgm4883> Might want to try and find out the wireless chipset and such
[22:10] <tgm4883> other than that, slightly more expensive laptop is slightly better
[22:11] <c_smith> ok
[22:13] <c_smith> tgm4883, if the driver is listed as Broadcom, would it be safe to say it's one of those?
[22:16] <tgm4883> c_smith, I usually like to do a google search for "ubuntu <laptop>"
[22:16] <c_smith> alright.
[22:16] <tgm4883> then read recent stuff like http://thecomputersarewinning.com/post/Ubuntu-Lenovo-IdeaPad-U400/
[22:16] <tgm4883> and http://www.lagserv.net/wp/2011/12/wireless-and-ubuntu-linux-on-the-lenovo-ideapad-u400/
[22:17] <tgm4883> the Z575 seems to have more people with issues
[22:18] <c_smith> alright.
[22:18] <MaskilPDX> I have been only upgrading my kernel when it's released by Ubuntu.  I see that 3.5.2 is out. I am running 3.2.0-29-generic-pae
[22:19] <MaskilPDX> Should I manually upgrade, or just wait
[22:19] <tgm4883> MaskilPDX, do you need 3.5.2?
[22:20] <MaskilPDX> That's the question, is it something I need?
[22:21] <bkerensa> tgm4883: u coming to debian beering tonight? :)
[22:21] <tgm4883> bkerensa, nope
[22:21] <bkerensa> if u left now u could make it
[22:21] <tgm4883> MaskilPDX, nope
[22:21] <MaskilPDX> Cool
[22:21] <MaskilPDX> Thanks tgm4883
[22:22] <tgm4883> MaskilPDX, I mean, I can't 100% answer that for you, but you are going to get security updates with 3.2.x
[22:22] <tgm4883> eventually 3.5.2 will make it into precise, but that would probably just get new features/hardware support
[22:23] <nathwill> c_smith, i've heard some awkward things about the ideapads
[22:23] <MaskilPDX> ok, as to not break anything, I will wait.
[22:23] <bkerensa> I hope we see some backporting in 12.10
[22:23] <bkerensa> nathwill: I think slangasek has one...
[22:23] <tgm4883> bkerensa, backporting in 12.10, or from 12.10?
[22:23] <bkerensa> he has some kind of lenovo
[22:23] <MaskilPDX> I am cool with adding/removing apps, but messing with the kernal makes me nervious
[22:24] <bkerensa> tgm4883: from 13.04 to to 12.10
[22:24] <bkerensa> ^ he just messed with the kernel
[22:24] <bkerensa> :)
[22:24] <bkerensa> c_smith: Here http://www.youtube.com/watch?v=CZPgMeF4YZM
[22:24] <tgm4883> bkerensa, ah
[22:25] <tgm4883> bkerensa, IDK if they are going to do that for non-LTS releases
[22:25] <bkerensa> yeah
[22:25] <bkerensa> =/
[22:25] <bkerensa> well Kernels are going rolling I hear
[22:25] <bkerensa> :)
[22:25] <tgm4883> it seems like there is a LOT more effort to make running LTS only feasible
[22:27] <bkerensa> nathwill: Acct Mgr job is gone :P
[22:27] <nathwill> hrm
[22:28] <nathwill> there was another job i saw there that i thought you might be interested in
[22:28] <nathwill> lemme see if i can find it
[22:28] <bkerensa> nathwill: I would do the Cus Care III
[22:28] <bkerensa> :)
[22:30] <bkerensa> nathwill: well I will see you at Lucky Lab... I need to start getting ready to head out that way :)
[22:30] <nathwill> the DAM job looks good too
[22:30] <nathwill> alrighty
[22:32] <nathwill> tgm4883, how is running lts more effort?
[22:34] <c_smith> if I can't find a single issue on google about a particular laptop, would that be a good thing or a bad thing?
[22:34] <c_smith> about a particular laptop and ubuntu, that is.
[22:34] <nathwill> c_smith: neutral!
[22:34] <c_smith> alright.
[22:34] <slangasek> bkerensa: an ideapad?  God forbid
[22:34] <c_smith> right now I'm looking at an Acer Aspire
[22:41] <c_smith> in case anyone is curious, this is the Acer Aspire i'm talking about: http://www.newegg.com/Product/Product.aspx?Item=N82E16834215411
[22:41] <bkerensa> nathwill: I am bringing some gadgets to giveaway :) a minipc and a arduino kit :)
[22:43] <nathwill> rofl
[22:43] <nathwill> no helicopter?
[22:48] <c_smith> think he's gone.
[23:01] <bkerensa> nathwill: you are going to hit so much traffic :P
[23:02] <nathwill> bkerensa, yes, i will
[23:02] <nathwill> but i don't get off until 6, so..
[23:02] <bkerensa> :)
[23:02] <bkerensa> oh
[23:02] <bkerensa> lol
[23:03] <bkerensa> nathwill: I dont know if you will make it at all then :)
[23:03] <bkerensa> lol
[23:03] <bkerensa> usually only lasts a hour or so
[23:03] <bkerensa> :)
[23:04] <nathwill> oh
[23:04] <nathwill> well
[23:04] <bkerensa> nathwill: I'm just jiving you :)
[23:04] <bkerensa> spreading a little FUD ;p
[23:04] <nathwill> boo
[23:10] <bkerensa> Looks like I wont be able to make it
[23:10] <bkerensa> >.<
[23:13] <bkerensa> great success :) found what I needed
[23:25] <nathwill> noticed we were missing a calagator event, so added: http://calagator.org/events/1250462771
[23:25] <nathwill> cloned from the last one
[23:28] <tgm4883> nathwill, if you buy hardware that isn't supported in the LTS
[23:28] <tgm4883> nathwill, if you want to upgrade an application and get new features in an LTS
[23:31] <nathwill> tgm4883, backports don't cover both of those?
[23:31] <tgm4883> nathwill, I don't think backports covers new hardware
[23:32] <nathwill> tgm4883, hardware enablement is explicitly blessed motive for SRU's...
[23:32] <nathwill> so that should be coming back
[23:32] <tgm4883> nathwill, new kernels are being backported to LTS releases. That is a new thing
[23:33] <tgm4883> backports also isn't enabled by default I think
[23:34] <nathwill> i just don't see where it's a lot more effort. (granted i'm generally running the alpha/beta because i'm twitchy like that)
[23:35] <nathwill> but from my understanding, those shouldn't be big issues in an lts
[23:37] <nathwill> the new software thing i think we talked about yesterday
[23:37] <nathwill> new apps rather, to be more specific
[23:40] <tgm4883> nathwill, compare 12.04 to 10.04
[23:40] <tgm4883> 10.04 was much harder to do that stuff in for an average user
[23:42] <tgm4883> nathwill, the next thing that needs to go is specifying which release you are targeting
[23:42] <tgm4883> I shouldn't need to build a source package 4 times just to support 12.04, 11.10, 11.04 and 10.04
[23:43] <tgm4883> nathwill, so what canonical has done is made it a lot easier for a user to run an LTS (with the advantages they have in 12.04 over what was available in 10.04), but they still have work to do to make it easier for a developer to get software into old versions
[23:44] <nathwill> tgm4883 i think you'd need statically linked libraries to avoid i
[23:44] <nathwill> t
[23:44] <tgm4883> nathwill, I don't think so, it would still build binaries for each distro release
[23:44] <tgm4883> but the source package shouldn't need to change much
[23:45] <tgm4883> of course it would require developers to actually know what they are doing
[23:46] <tgm4883> you just handle everything though dependencies. Instead of depending on packageX, you depend on packageX-VERSION (or better yet, >> packageX-VERSION)
[23:47] <tgm4883> then push it to build servers, and build servers figure out what distro releases have those packages and build for all
[23:47] <nathwill> :/ we're stepping out of my comfort zone, but i suspect that if it was as easy as you make it sound (just procedural issues), we wouldn't be where we are
[23:47] <tgm4883> nathwill, IDK about that, there is stuff in the debian spec that isn't even supported yet in debian
[23:48] <tgm4883> eg. specifying multiple distro releases in a debian/changelog file for building
[23:49] <tgm4883> slangasek could probably correct me if I'm wrong here, but it seems that either A) you are right and this is much harder than it should be (which is possible, I could be missing something) or B) nobody has gone though the effort to actually do it yet
[23:49] <tgm4883> B is the case for the multi release spec
[23:51] <tgm4883> in any case, there is need to keep building stuff for 12.04 after 12.10 is released, but I don't think developers are going to bother doing that
[23:51] <nathwill> i think the variety of software available for multiple releases says otherwise :/
[23:54] <tgm4883> nathwill, is there much application development going on for 10.04 or 11.10 still?
[23:56] <nathwill> http://packages.ubuntu.com/lucid-updates/firefox
[23:56] <tgm4883> nathwill, firefox doesn't count
[23:56] <nathwill> orly?
[23:57] <tgm4883> nathwill, anything with a MRE doesn't count
[23:57] <tgm4883> Anything that the security team backports security fixes for doesn't count
[23:58] <tgm4883> we're talking regular programs with new features
[23:58] <tgm4883> ala. libre office