[00:07] <wgrant> Mmmmmm sub-second batching
[02:46] <lifeless> wgrant: including rtt?
[02:47] <wgrant> lifeless: Yes
[02:47] <wgrant> lifeless: 0.85 browser time for an ubuntuone-servers batch on qas
[02:47] <wgrant> 0.85
[02:47] <wgrant> s
[02:56] <lifeless> nice
[08:02] <lifeless> hmm, I suspect we need to move to 2pc
[08:04] <lifeless> will solve a raft of failure modes around SOA
[08:07] <nigelb> bigjools: You need to taste good turkish delights :D
[08:39] <czajkowski> morning
[08:44] <wgrant> Morning czajkowski.
[08:45] <czajkowski> wgrant: howdy
[08:49] <lifeless> http://www.webperformancetoday.com/2012/03/21/neuroscience-page-speed-web-performance/


 my mother has now joined #TeamAW from #TeamPebble
[02:47] <floridagram> * ahoneybun pokes @thumbs88
 @KMyers still around?
 @ahoneybun, What's up
 I can't get iframe to work in wordpress
 works over here: http://kubuntu.org/support/?preview_id=612&preview_nonce=56ac5d8d7d&_thumbnail_id=1341&preview=true
 ops
 http://kubuntu.org/support/
 Why are you trying to use an iframe? I would not if you can avoid it as they look horrible
 I want IRC on the site
 like on Kubuntu.org
 The kiwiIRC is showing up for me
 on Kubuntu
 but not our site
 https://ubuntu-fl.org/index.php/irc/
 this is the kubuntu one: <iframe src="https://kiwiirc.com/client/irc.freenode.net/?nick=user|?#kubuntu" style="border:0; width:100%; height:450px;"></iframe>
 we don't have any plugins on it tho
 Ah. You cannot include code in the WordPress default WordPress rich text editor. You need to use the raw "text" option
 Just don't switch back to the rich text editor before hitting save
 ahhh
 @KMyers works now
 thanks a ton
[03:05] <ubuntuFL|68108> \o
 NP - still not a fan of iframes for the record
 find something that works as easy and I'll take it any time
 lol
 this watch charges stangely
 was just at 93 and now at 92
 tease
 I just switched from gs8 plus to gs8.  I couldn't handle the girth.  It was too much for me.
 @KMyers what do you think about keepass?
 I'm considering switching.
 @AdamOutler, It is an excellent password manager but a lot of features that I require need plugins which are not always cross platform.
[03:41] <maxolasersquad> AdamOutler, I'm a long time user of KeePass and a big proponent of it.
 Downloads - KeePass … http://keepass.info/download.html
 Which use is not supported?
 https://www.keepassx.org
 Why would I choose keepassx over keepass?
 From what I could find.
 "Currently, the biggest difference between KeePass & KeePassX seems to be the appearance and "feel" of each program, especially on Linux or Mac OS X where KeePassX doesn't rely on Mono, so matches the look of other native programs closer. And, KeePassX's version 0.4.x & 2.x display issues."
 https://superuser.com/questions/878902/whats-the-difference-between-keepass-and-keepassx
 @SivaMachina, So far
 So mostly cosmetic and dependency differences. I take it as more compatible with Linux.
 Keepass seems to have more support on platforms.
 @ahoneybun - https://yuenhoe.com/blog/2017/04/nextcloud-plugin-for-quickshare/?utm_content=buffer593ab&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
 nice
 http://www.androidauthority.com/nuans-neo-reloaded-campaign-767429/?utm_source=dlvr.it&utm_medium=gplus
 @all


[09:00] <ppisati> morning
[09:31] <cking> yawn
[09:41]  * apw yawns
[09:42] <lilstevie> cmorning
[09:42] <lilstevie> -c
[10:03] <Q-FUNK> in Oneiric, I regularly get notices from various CLI and GNOME apps that memory forking failed. I have never seen this until now. What causes this? To answer an obvious question, I indeed have a (large enough) swap partition.
[10:04] <apw> Q-FUNK, what is the exact text of the message
[10:04] <apw> as memory forking really doesn't make any sense
[10:07] <Q-FUNK> fork epäonnistui: Muistin varaaminen ei onnistu
[10:08] <Q-FUNK> (fork failed: memory allocation failed)
[10:08] <Q-FUNK> that's from CLI
[10:08] <Q-FUNK> I see a similar message from gnome-shell whenever starting GUI apps from it, too.
[10:09] <apw> ok so some memory pool or other was depleted at the time of the fork.  this may not be a general pool of course
[10:09] <apw> was there anything notable at the bottom of the dmesg at the same time
[10:10] <Q-FUNK> nothing malloc related.
[10:12] <Q-FUNK> in fact, the newest dmesg entry is from about 30 minutes ago and not memory related at all.
[10:12] <apw> a tricky one then, as ENOMEM has any number of actual meanings not all even related to memory (such are the vaguaries of error codes)
[10:12] <apw> is this 32 or 64 bit
[10:13] <apw> it isn't a general issue for everyone as none of my oneiric installs are seeing it
[10:13] <Q-FUNK> 32-bit.  686 centrino
[10:13] <Q-FUNK> it could be that my swap partition has gone awry but since nobody ever got around inveting any fsck.swap, I wouldn't know.
[10:14] <apw> swap is empty once you reboot, it isn't persistant
[10:14] <apw> (deemed empty)
[10:14] <apw> but you might check it is actually activated
[10:14] <Q-FUNK> that says nothing about the sanity of the blocks within the swap partition.
[10:14] <apw> define sanity, the kernel should never assume the contents of any of them after reboot
[10:14] <Q-FUNK> Swap:          494        494          0
[10:15] <Q-FUNK> well, does the kernel at least perform a badblock check on it at reboot?
[10:15] <apw> nope, no bad block scans.  modern drives are assumed to remap blocks
[10:16] <apw> you should however get errors in dmesg for disk realted failure
[10:17] <Q-FUNK> ok
[10:17] <apw> is the failure persistant or transient
[10:18] <Q-FUNK> random.  mostly seems to happen whenever firefox has run into too many broke javascripts and started utilizing more than 60% of available memory.
[10:18] <apw> and you don't have to do anything for the next attempt to be successful ?
[10:18] <Q-FUNK> which attempt?
[10:19] <Q-FUNK> at doing what?
[10:19] <apw> you do "something" and it fails, you do "something" again and it works?
[10:19] <lilstevie> running what ever throws the error message
[10:19] <apw> or you do "something" and it fails, you take a machette to various programs, and you do "something" and it works
[10:20] <Q-FUNK> it doesn't work again until I have Quit Firefox, let it close itself down and reached 0% of resource consumptions.
[10:20] <Q-FUNK> then, other applications are able to malloc again.
[10:21] <apw> so it could genuinly be an issue with firefox then
[10:21] <apw> could we sub in say chromium for a few days to see if that is immune
[10:22] <Q-FUNK> possibly.  then again, I wonder why the kernel would let firefox consume all the resources to the point of also filling the swap.
[10:22] <apw> why would the kernel not let you fill up all your resources with things you are running
[10:22] <apw> if you overcommit all of ram and all of swap on your system, it cannot do anything to help you
[10:23] <apw> how much swap do you even have
[10:23] <Q-FUNK> it can TERM the offending app.
[10:23] <apw> in a serious memory crunch it would, but it takes the simpler
[10:23] <apw> and safer course and prevents you asking for more in your fork
[10:24] <apw> at least that way you get to chose which apps are surplus and kill those cleanly
[10:24] <apw> instead of them going pop and you getting annoyed cause it loses something
[10:24] <Q-FUNK> grsec was very good at this. if an app requests an insane amount of RAM, it would sigterm it.  if that didn't do the trick, it would sigkill it.
[10:25] <apw> that this is new, that it "only" happens with firefox, and exiting firefox restores the world tends to lean to a problem with firefox leaking memory
[10:25] <Q-FUNK> well, the thing is that a normal user wouldn't know what those messages mean or how to debug it.  here, I happen to know about 'ps' and 'top' enough to notice, but even then.
[10:25] <lilstevie> but in your case it really isn't requesting an insane amount of ram, it is taking it over time :)
[10:25] <apw> and they would not be able to cope with apps dieing at random when they got big either
[10:25] <lilstevie> apw: my thoughts exactly
[10:26] <apw> that your machine wasn't too small on natty and is on oneiric it says there is a bug somewhere
[10:26] <apw> that exiting firefox helps means its less likely to be a kernel memory leak
[10:26] <apw> as those tend to just persist across exiting the app
[10:26] <apw> so i'd start by blaming firefox, and try and prove that is to blame
[10:27] <apw> subbing in an equivalent app temporarily should tell us something i'd hope
[10:27] <Q-FUNK> it probably is.  firefox has never been a well-behaved app.
[10:27] <apw> they would be very interested to know if they are broken though
[10:27] <apw> they are pretty popular
[10:28] <lilstevie> judging from what you said about it being after running too many broken javascripts, it is most likely in the javascript parser
[10:30] <apw> yeah, or indeed if the apparent brokenness of those is a side effect
[10:31] <lilstevie> yeah
[10:33] <Q-FUNK> well, I simply notice that after firefox has popped too many alerts about runaway scripts, asking me if I want to intereupt them, its memory consuption goes to absurd extremes.
[10:34] <Q-FUNK> it apparently doesn't know about freeing the memory after stopping those runaway scripts.
[10:34] <lilstevie> so that could be part of the effect not the cause
[10:35] <apw> Q-FUNK, are these alerts new or more frequent since the upgrade
[10:43] <Q-FUNK> apw: they started happening since oneiric.
[10:44] <apw> so lets start with a bug against firefox
[10:44] <Q-FUNK> before that, the kernel never had any problem offering more memory to new applications, even though it sometimes resulted in furious drive spins because of heaving swaping.
[10:46] <Q-FUNK> i wonder if we could make apparmor TERM firefox gently when it exceeds a certain amount of memory usage, though.
[10:47] <lifeless> Q-FUNK: that would rather stop it being usable
[10:47] <lifeless> Q-FUNK: its not exactly svelt
[10:47] <apw> i personally would rather find new thing stopped, than existing things just dissappeared when i wasn't looking
[10:47] <apw> the user experience is very poor if firefox just goes pop
[10:47] <Q-FUNK> it becomes unusuable after it exceeds a certain amount of memory usage anyhow. it becomes as slow as molasses.
[10:48] <apw> yes and you can click remember this specific page and the like, read whats there, make a decision to close it
[10:48] <lifeless> Q-FUNK: mine is up at 3G, still responsive
[10:48] <apw> either way its sick and needs a bug
[10:48] <Q-FUNK> right, except that stoping new apps doesn't tell anything useful to the user as to why new apps cannot be launched.
[10:48] <apw> 3G for firefox, wtf
[10:48] <apw> and it dissappearing is better.  neither is good
[10:49] <lifeless> apw: yes, which is lean compared to chromium :)(
[10:49] <apw> and it is clearly broken papering over it isn't appropriate
[10:49] <Q-FUNK> I cannot use chromium. its resource consumption has become even worse than FF3 used to be.
[10:50] <apw> well then even more of a reason to file a bug on it
[10:51] <Q-FUNK> FF4 and newer eventually became slightly better at resource consumptions, but the handling of broken content is still dumb.  it expects users to add items to an ever-growing blacklist, rather than have a sane policy of killing faulty content after a while and asking the user whether we should attempt to re-load.
[10:53] <Q-FUNK> I've already suggested changing that model to upstream.  never got any response.
[10:53] <lilstevie> browsers have been pretty bad lately
[10:54] <apw> feature creap
[10:54] <Q-FUNK> instead of waiting for content to go awry and request 100% of availble resource and then try to allocate more resources for a pop-up asking the user whether it should kill the bad content,
[10:55] <Q-FUNK> I suggested that it should promptly kill misbehaved content and then notify the user that this happened, offering to reload.
[10:55] <lilstevie> my uptime is pretty low at the moment cause I just rebooted, and chrome is already using 490MB ram on 8 tabs
[11:03] <Q-FUNK> lilstevie: I'm not surprised. here, I keep chromium as a backup, in case firefox really becomes unusable, so that I at least have something to access online banking, but even then, I'm not putting my hopes too high.
[11:04] <Q-FUNK> mind you, I wouldn't entirely put the blame on browsers (at least not for recent firefox).  rather, the issue is all those sites with real-time content refresh and tons of javascript.
[11:06] <Q-FUNK> by the time you have 20 tabs, each trying to refresh the number of Facebook Likes for that page and the number of backtracks on every syndicated blog, in real-time, even the new and improved firefox slows to a crawl in no time.
[11:15] <lilstevie> heh I don't do that stuff
[11:15] <lilstevie> I have 2 self updating pages
[11:16] <lilstevie> uni email, and my domains webmail, powered by gmail
[11:23] <ppisati> herton: O/ti-omap4 3.0.0.-1206-11 has been superseded by 3.0.0-1207-12, so according to the new workflow i should mark as "duplicate" the old tracking bug
[11:23] <ppisati> herton: but does it apply even if 1206-11 is already in -proposed?
[11:24] <herton> ppisati: yes, we will just build the new package to replace the old one in -proposed
[11:24] <ppisati> ok
[13:35] <njin> Hallo, what do you blame linux or xorg ? bug 881830 thanks
[13:35] <ubot2> Launchpad bug 881830 in linux "Track pad does not respond properly" [Undecided,Confirmed] https://launchpad.net/bugs/881830
[13:46] <apw> njin, hard to say, likely as its an apple product its something stupidly complex and undocumented
[13:46] <apw> you may be able to tell using input-events on the appropriate input channel
[13:46] <apw> if you see the 'wrong' clicks etc there then its kernel side
[13:46] <apw> but being an apple touchpad, we may well not be able to do anything
[13:48] <apw> njin, also do we know why they are running a random upstream kernel?
[13:51] <njin> apw, thanks is an ubuntu member using the macbook
[15:02]  * ogasawara back in 20
[17:12] <herton> ppisati: still around?
[17:22] <ppisati> herton: yep
[17:23] <herton> ppisati: I was looking at the ti-omap4 (oneiric), does it need an abi bump on the new rebase?
[17:24] <herton> ppisati: on the latest rebase you did, from 1206.11 to 1207.12
[17:27] <herton> ppisati: as there was only the rebase, and the master oneiric tree didn't bump the abi from 13.21 to 13.22, I was expecting the ti-omap4 to not bump as well
[17:30] <apw> -       $(kmake) O=$(hdrdir) -j1 silentoldconfig prepare scripts
[17:30] <apw> +       $(kmake) HOSTCC=$(CROSS_COMPILE)gcc KBUILD_SCRIPTROOT=$(kbsr) O=$(hdrdir) -j1 silentoldconfig prepare scripts
[17:37] <ppisati> herton: but it goes from Ubuntu-3.0.0-13.20 to -22 in my case
[17:37] <ppisati> herton: the rebase i mean
[17:44] <herton> ppisati: well, I see it here only as a rebase between 13.21 to 13.22 (12.20 was the previous from these two): http://pastebin.ubuntu.com/731144/
[17:47] <herton> ppisati: do you get a abi mismatch or some like that while building after the rebase?
[17:48] <herton> (the diff from pastebin is the differences between origin/ti-omap4 and your ppisati ti-omap4 with commits removed so the diff is easier spotted)
[17:48] <ppisati> herton: wait
[17:52] <smoser> smb`, you have any thoughts on a target for having bug 881076 fixed ?
[17:53] <ubot2> Launchpad bug 881076 in linux "precise kernels do not boot on ec2" [High,Triaged] https://launchpad.net/bugs/881076
[18:26]  * tgardner -> lunch
[18:30] <ppisati> herton: should be fixed now
[18:31] <herton> ppisati: thanks, will check and push
[18:58]  * ppisati -> bails out
[19:14] <jsalisbury> bjf, sconklin, herton regression in Lucid, that has a possible commit identified that caused the issue: bug 875300
[19:14] <ubot2> Launchpad bug 875300 in linux "[Realtek ALC268] ALSA test tone not correctly played back (regression in lucid from 2.6.32-33.72)" [Medium,Triaged] https://launchpad.net/bugs/875300
[19:15] <herton> jsalisbury: ack, we will check that
[19:15] <jsalisbury> herton, thanks
[20:09] <jdstrand> tgardner: hey. your --reap patch to iptables pretty much has to be reworked for iptables 1.4.12
[20:10] <tgardner> jdstrand, um, how so ?
[20:10] <jdstrand> tgardner: upstream made quite a few changes. I'd like to do the merge, but don't want to rewrite your patch. I'm wondering how to proceed-- perhaps I could do the merge and back out the --reap change, and then file a bug for that functional regression and assign it to you?
[20:11] <tgardner> jdstrand, you mean the user space portion? I thought that got accepted upstream.
[20:11] <jdstrand> tgardner: they redid the struct and the arg parsing, etc
[20:11] <jdstrand> tgardner: (yes the userspace bits) no it didn't. we've been carrying this delta for a long time
[20:12] <tgardner> jdstrand, huh. ok, I'll see about getting the patch redone and accepted upstream
[20:12] <jdstrand> tgardner: sounds great. looks like openwrt picked it up (noticed in my google search)
[20:13] <jdstrand> so hopefully upstream will be willing
[20:13] <jdstrand> I'll back it out for now and assign a new bug to you
[20:13] <tgardner> jdstrand, ok, thanks for the note
[20:14] <cnd> tgardner, ogasawara: I tested hid-ntrig in oneiric vs the latest daily mainline
[20:14] <cnd> I motion for reverting all our patches and just going with upstream
[20:14] <ogasawara> cnd: Ooo, nice
[20:14] <tgardner> cnd, in oneiric or precise ?
[20:14] <tgardner> or both
[20:14] <cnd> tgardner, in precise
[20:14] <cnd> I don't want to mess with oneiric
[20:14] <tgardner> cnd, works for me.
[20:14] <cnd> though I'll be requesting a hardware ID addition soon
[20:15] <cnd> however, I don't know how to send patches for this
[20:15] <tgardner> cnd, that is a deeply curious statement
[20:16] <cnd> sorry, I need to be more clear
[20:16] <cnd> I know how to send a patch for the new ID that needs to go into an oneiric SRU
[20:16] <cnd> I don't know how to fix up precise
[20:16] <cnd> the git log in precise for drivers/hid/hid-ntrig.c does not show the upstream commits at all
[20:17] <cnd> I expected to see upstream, then a bunch of upstream reverts until our commits applied cleanly, then our commits
[20:17] <cnd> but I only see upstream up to 7b2a64c96ad53c4299f7e6ddf8c2f99cb48940a9
[20:17] <tgardner> cnd, are you assuming we've been following the merge window? we generally don't until -rc1
[20:17] <cnd> then sauce patches
[20:18] <cnd> tgardner, there's been no change to ntrig during this merge window
[20:18] <tgardner> cnd, huh, you should consult with ogasawara I guess
[20:18]  * tgardner ducks out for a moment
[20:19] <cnd> if I had to take a stab, I would send a pull request which included ~10 sauce patch reversions and then another ~10 upstream patches that we don't have
[20:21] <ogasawara> cnd: this is what I see --> http://pastebin.ubuntu.com/731333/
[20:22] <ogasawara> cnd: so I assuming you're saying we can drop the first 10?
[20:22] <ogasawara> ie revert the following:
[20:22] <ogasawara> 961ed450b0e8019a615774712b05db18e36bbea7 UBUNTU: SAUCE: HID: ntrig: fix suspend/resume on recent m
[20:22] <ogasawara> 712ad9598cb31639546faa2b57311bc32145a978 UBUNTU: SAUCE: HID: hid-ntrig: add support for 1b96:0006
[20:22] <ogasawara> b624fabc45a8b9bd42af2f066ce52934d44df028 hid: ntrig: Mask pen switch events
[20:22] <ogasawara> f5180d5875606b3e4fd68be65373326e60c835b6 hid: ntrig: Support single-touch devices
[20:22] <ogasawara><PHONE_NUMBER>8464f35574fec4e0360d6cce32a742 UBUNTU: SAUCE: hid: ntrig: New ghost-filtering event logi
[20:22] <ogasawara> b0613584b5f5c2c393ba46fcab5ea073f15cef95 UBUNTU: SAUCE: hid: ntrig: Setup input filtering manually
[20:22] <ogasawara> 25826a386b28c76aa9580b05d5c75f5ade02f781 UBUNTU: SAUCE: hid: ntrig: remove sysfs nodes
[20:22] <ogasawara> 489814f46a3c69da2109a076a81620aeb476b927 UBUNTU: SAUCE: hid: ntrig: zero-initialize ntrig struct
[20:22] <ogasawara> 4fff4d1f822e3dc85942598cbe2727f1bdb271bb UBUNTU: SAUCE: hid: ntrig: Correct logic for quirks
[20:22] <ogasawara> 5dc230ad38578ceb9d88218eb6507bf0b858dab6 UBUNTU: SAUCE: hid: ntrig: Remove unused device ids
[20:23] <cnd> ogasawara, yep
[20:24] <cnd> ogasawara, and then pull in all the latest upstream changes
[20:24] <cnd> oh wait
[20:24] <cnd> I guess they all are in the tree
[20:25] <ogasawara> cnd: right, there's no additional changes upstream we'd need to pull in
[20:25] <cnd> yeah
[20:25] <cnd> so reverting those commits is all that needs to happen
[20:26] <cnd> somewhere in those commits there must be a large amount of changes that are nothing but reversions of previous upstream commits :)
[20:26] <ogasawara> cnd: cool.  how about I build you a quick test kernel with the 10 commits reverted just confirm before I actually drop them.
[20:26] <cnd> ogasawara, sure
[21:43] <jjohansen> apw: you still around
[21:44] <ogasawara> cnd: test kernel -> http://people.canonical.com/~ogasawara/ntrig/
[21:44] <cnd> ogasawara, thanks!
[22:11] <cnd> ogasawara, kernel looks good
[22:11] <cnd> is there anything else you need me to do?
[22:11] <cnd> I can send a pull request for the revert if you like
[22:52] <cosmosis> I am installing ubuntu 11.10 on a brand new system.  8 core AMD FX-8150 CPU with a ASUS M5A97 -- AMD 970 motherboard and 16 gig of ram.   When I go to install I get as far as  864 and detecting the usb keyboard and then it just hangs.  Any ideas?
[22:53] <holstein> cosmosis: unplug the keyboard
[22:53] <cosmosis> ok will give it a shot
[22:58] <cosmosis> now its getting hung after 5.36 detecting the sr0 device (cd drive)
[22:59] <cosmosis> its not locked its just sitting there sort of..
[22:59] <cosmosis> but its not proceeding with install
[23:00] <holstein> i would probably just start testing the hardware to make sure
[23:00] <holstein> you can try #ubuntu and/or #ubuntu-beginners as well... this is not really a support channel
[23:01] <cosmosis> ok sorry its just I tried the ubuntu-installer channel and they said ask the kernel guys
[23:38] <ogasawara> cnd: no need to do anything else.  I'll just add a note to the commits that they were dropped per our delta review.
[23:47] <cnd> ogasawara, great
[23:47] <cnd> ta


[00:08] <ykaya> does anyone have toshiba qosmio series laptop or toshiba laptop with illuminated touch sensitive buttons?


[06:09] <Hew> bug #224366 is a dupe but I can't find the original bug. It's that issue where an app can't access the sound device because it's in use by pulseaudio. eg, flash videos don't play while rhythmbox does. Surely it's a big bug somewhere; can anyone find it?
[06:12] <Rocket2DMn> Hew, i think youre right, but i dont think its with flashplugin-nonfree specifically
[06:12] <Hew> yea I think it was pulseaudio
[06:12] <Hew> I know Wine gets blocked too
[06:13] <Hew> ah, I think this is it: bug #183917
[06:14] <Hew> sorting reports by number of duplicates really helps :-)
[07:57] <NCommander> Why is grabbing the Session causing mod_python to crash
[13:54] <philsf> how can I set status of a bug per release?
[13:55] <philsf> I "nominated" the bug for hardy and intrepido, but can't find where to set the status for each
[13:55] <philsf> https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/128074
[13:56] <philsf> Bug #128074 is "Fix Released" for Intrepid, and "New" for Hardy.
[14:00] <james_w> philsf: you can only do that once it has been approved
[14:00] <james_w> nominating means that it shows up on a list for consideration, from which it will be either accepted or declined. If it is accepted then you can change the status in each release.
[14:01] <philsf> oh.. you sound as if I shouldn't have done it..
[14:01] <philsf> sorry for that
[14:02]  * philsf feels like a kid that dropped something
[14:02] <seb128> philsf: I doubt it'll be accepted, that's not a trivial change and the comments indicate it's not perfect, not something for stable updates
[14:03] <james_w> philsf: I didn't mean that, sorry if I gave that impression.
[14:04] <philsf> seb128: I see. I still think it's important that this is fixed, especially in an LTS release. the LTS should be the one used in academic workplaces, but this is really a stopper for newbies.
[14:04] <seb128> philsf: well if there is a solid patch available I'm not against it but so far nobody suggested one
[14:05] <philsf> of course one could use one of the plethora other choices for pdf readers, but in gnome, they are all slower than evince
[14:05] <philsf> seb128: I see. thanks for your comments, though. can I revert the improper nomination?
[14:06] <seb128> not sure, I've the privileges to accept or refuse those so I don't know what interface the people who don't get
[14:06] <philsf> james_w: no worries. I should have read.... something... before messing with bug statuses
[14:06] <seb128> but just wait for somebody to accept or reject it that's no issue
[14:06] <philsf> maybe this should be accepted, and turned hardy state to invalid?
[14:08] <philsf> I just posted the informative last post to upstream, so they see the new screenshot, and know about the still wrong "fi" string problem. maybe if there's a fix, someone can backport the patch to poppler 0.6.4
[14:08] <philsf> k, thanks sebastian
[14:09] <pereza> Hi. that is a problem for new peple when working with bugs. Sometime I say to myself if it is ok to change thing in the bug report
[14:09] <seb128> philsf: did you try in intrepid using 0.8? does it work correctly on this version?
[14:10] <philsf> seb128 I can't install intrepid right now, and have no time to learn about VMs, sorry
[14:10] <philsf> not that I wouldnt like it
[14:10] <seb128> maybe you can download a liveCD and give it a try?
[14:10] <seb128> no need to install
[14:10] <philsf> seb128: how could I forget that...
[14:11] <seb128> philsf: see, there is always a solution ;-)
[14:12] <philsf> pereza: yeah, maybe lp could have some help links or ballons
[14:12] <philsf> new alpha tomorrow? I'll do it then
[14:14] <pereza> question here, bug 224589, do we need to know which version of ubuntu he/she is running?
[14:19] <pereza> philsf, any ideas?
[14:27] <philsf> pereza: can you reproduce it?
[14:30] <philsf> pereza: I always assume bug reporters are using the latest release at the time of the posting. people who are lazy enough to upgrade, aren't exactly the most common bug reporters
[14:30] <philsf> nevertheless if you(someone) can reproduce it in hardy, that's what counts
[14:41] <pereza> philsf, thanks for the info
[15:21] <Jazzva> jcastro, ping
[15:22]  * persia generally encourages contentful pings, even when only one person can be any help at all.
[15:23] <jcastro> Jazzva: yo!
[15:23] <Jazzva> ok :)
[15:24] <Jazzva> jcastro, could you please prolong my membership in ubuntu-bugcontrol. I received notification that it's about to expire
[15:24] <Jazzva> persia, thanks for the advice...
[15:24] <jcastro> Jazzva: one moment
[15:25] <Jazzva> jcastro, ok
[15:25] <jcastro> hmm, I have no idea how to do that
[15:26] <persia> Jazzva: Can you not extend it yourself?
[15:26] <jcastro> I don't see anywhere in the UI on how to manage membership length in a team
[15:26] <Jazzva> persia, I'm not sure I can...
[15:27] <jcastro> I think when it expires it sends you a mail to extend?
[15:27]  * persia looks at the new UI, having done this before
[15:27] <Jazzva> persia, nope... I think administrator only can do that.
[15:27] <Jazzva> *only administrator
[15:28] <Jazzva> jcastro, https://edge.launchpad.net/~ubuntu-bugcontrol/+members , there should be a pen icon on the right of every row. My name is Saša Bodiroža, so you can search with that
[15:28] <persia> Jazzva: What do you get when you visit the team page in LP?  I think you should get a menu item to renew.
[15:28] <jcastro> ah, I see it, thanks
[15:29] <persia> jcastro: As an admin, if you show all members (/+members) you can edit specific members.
[15:29] <james_w> jcastro: hi, could you extend mine while you are at it please?
[15:29] <Jazzva> pereza, I can't find that option.
[15:29] <jcastro> yep, found it, you're all set Jazzva
[15:29] <Jazzva> ups, persia
[15:29] <james_w> hi persia
[15:29] <persia> james_w: Hi
[15:29] <Jazzva> jcastro, thanks :)
[15:29] <jcastro> james_w: all set
[15:29] <james_w> great, thanks.
[15:56] <jonpackard> I'm trying to run a backtrace using gdb for a problem in Tomboy.. I'm getting an error about /usr/bin/tomboy not being an executable.. could anybody please help me with this please? See http://pastebin.com/f64be32fd for full output. Thanks!
[15:59] <persia> jonpackard: tomboy is a bash script.  You might find more information there about how to get a trace.
[16:00] <persia> That said, you may do just as well to turn on apport and report it that way (see https:/wiki.ubuntu.com/Testing/EnableProposed for instructions on activating apport
[16:01] <jonpackard> persia: thanks! I'm actually confirming bug 250502 and wanted to include a backtrace for more info
[16:03] <persia> jonpackard: If you can discover a good generic way to do it, it might be good to add some information on how to debug Mono apps.  As much as I like backtraces, I'm not sure how to get a good one for those.
[16:10] <seb128> the current handling of mono crashes is not good
[16:10] <seb128> getting a gdb stacktrace of the mono interpreter is usually not that useful
[16:11] <seb128> would be nice if somebody could write special handling for mono crash, similar to what is done for python crashes
[16:12] <seb128> also GNOME crashing is likely either a gnome-session or xorg bug
[16:13] <NCommander> seb128, well, right now, a big mono fix for a lot of the random segfaults went in
[16:13] <NCommander> (it was caused by some "genius" commenting out an entire block of code; I rewrote the patch to do it right, and it went upstream"
[16:13] <seb128> ah, good to know
[16:15] <NCommander> yeah
[16:15] <NCommander> I want to backport to Hardy
[16:15] <NCommander> But I haven't been able to find or write a test case that proves its affected beside having the same braindead code fix
[16:15] <jonpackard> Thanks for the help. Which package provides Mono? I want to include that when I confirm the bug about Tomboy.
[16:16] <NCommander> jonpackard, mono provides mono ;-)
[16:16] <NCommander> postscript is an ASCII format, right?
[16:17] <jonpackard> jon@bjh34kj54b:~$ apt-cache policy mono
[16:17] <jonpackard> mono:
[16:17] <jonpackard>   Installed: (none)
[16:17] <jonpackard>   Candidate: (none)
[16:17] <jonpackard>   Version table:
[16:17] <jonpackard> =(
[16:18] <seb128> jonpackard: mono-jit
[16:18] <persia> postscript may be unicode, but is usually also ASCII
[16:18] <persia> (or rather UTF8)
[16:19] <jonpackard> seb128: Thanks! That did the trick. :)
[16:23] <NCommander> the wiki running slow >.<;
[16:23] <NCommander> I finished the inital report though
[16:23] <seb128> yeah, the wiki is always slow apparently
[16:24] <NCommander> seb128,
[16:24] <NCommander> er
[16:25] <NCommander> bah
[16:25] <NCommander> https://wiki.ubuntu.com/MainInclusionReportlibspecrte
[16:25] <seb128> NCommander: you typoed the title ;-)
[16:25] <NCommander> Not a great way to start this off
[16:26] <NCommander> There won't be an easy way to rename a page?
[16:26] <seb128> NCommander: there is
[16:26] <NCommander> I don't see alink
[16:26] <seb128> the other actions combo has it
[16:36] <bdmurray> ogasawara: I've found a new kernel bug w/o a package should it just go straight to linux?
[16:36] <bdmurray> ogasawara: or should a 2.6.22 task be opened?
[16:48] <bdmurray> ogasawara: did you see my question?
[16:49] <ogasawara> bdmurray: I didn't, what was it?
[16:50] <bdmurray> I saw a gutsy kernel bug w/o a package and wasn't sure if it should go straight to 2.6.22 or linux
[16:50] <ogasawara> bdmurray: I'd push it to linux and ask for testing against hardy
[16:51] <bdmurray> well, I've lost the bug now but okay ;)
[17:56] <bdmurray> thekorn: your greasemonkey script is really neat
[18:17] <bdmurray> mvo: have you seen that tomorrow is a hug day for apt?
[18:18] <mvo> bdmurray: no, that is nice, I look forward to it
[18:24] <bdmurray> mvo: could you look at bug 228127?
[18:25] <mvo> bdmurray: sure
[18:26] <bdmurray> mvo: its already for fixing! ;)
[18:27] <mvo> bdmurray: thanks, commited to my main branch
[18:31] <bdmurray> mvo: great, thank you!
[18:33] <mvo> bdmurray: thank you! it will be part of the next regular upload
[18:33] <bdmurray> mvo: bug 209049 too
[18:36] <mvo> bdmurray: done
[18:54] <mouz> I forwarded a bug upstream, but now i'm not sure how to link to the remote bug. I'm confused by the existence of tasks already and also I'm not sure what is a 'project' and what is a 'distribution' in this context. Would like some help :) bug 239926 Thanks.
[18:54] <persia> mouz: To where did you forward it?
[18:55] <mouz> persia: bugzilla.mozilla.org
[18:55] <persia> URL?
[18:55] <mouz> https://bugzilla.mozilla.org/show_bug.cgi?id=447646
[18:56] <bdmurray> mouz: https://wiki.ubuntu.com/Bugs/Watches
[18:56] <persia> mouz: OK.  You'll notice that the bug has two tasks: one for Ubuntu, and one for Upstream.
[18:56] <persia> If you click the little arrow to the left of the Upstream task (the top one), it will provide an entry box for you to put that URL.
[18:57] <mouz> persia: yes (bdmurray i will read it later thanks)
[18:57] <mouz> yes
[18:58] <mouz> persia can i trust that small icon left of the first row is saying 'this is an upstream task'?
[18:59] <persia> mouz: Not quite.  The distribution tasks are of the form "package (distribution)".  The project tasks are of the form "project name".  Ideally, each project is upstream, although there are a couple exceptions remaining to be cleaned up.
[19:01] <mouz> persia: persia: ok. so just past the URL after 'URL:'?
[19:01] <mouz> s/past/paste/
[19:02] <persia> mouz: I believe that should work.  You might also have to adjust the radio button.
[19:02] <persia> Check the status of the main page and make sure there is a link under "Assigned" to verify.
[19:02] <mouz> persia: yes. thanks. it looks right now.
[19:04] <mouz> still i do not really understand what is a project, what is a distribution...
[19:05] <persia> mouz: A project is a collection of code creating one or more associated applications that work in a variety of environments.
[19:05] <persia> Examples include ardour, open office, mozilla, tkgate, etc.
[19:05] <persia> A distribution is a collection of projects and glue to build a complete operating environment for a computer.
[19:06] <persia> When tracking bugs, we distinguish between the status in Ubuntu (the distribution) and the status upstream (the project) as something may be fixed in one place first, and someone may need to manually migrate the fix into the other.
[19:09] <mouz> persia: What would be a reason to ever add a distrotask for another distribution then Ubuntu (if there is any)?
[19:11] <persia> mouz: Well, it might be that Ubuntu wants to track something in an upstream distribution (e.g. Debian), or a downstream distribution (e.g. Baltix) wants to track Ubuntu.
[19:12] <persia> Remember, while LP is often used for Ubuntu, it is also used for other projects and distributions.
[19:14] <mouz> Ok I understand now. Thanks persia. bdmurray thanks a lot for the link, I will read it now.
[19:26] <thekorn> bdmurray, I'm glad you like the gm script,
[19:27] <thekorn> my next plan is to add some black/whitelist to this script
[19:27] <thekorn> but than it should be complete
[19:28] <bdmurray> cool, well let me know and I'll merge it.  If you could update the README too that would be outstanding
[19:29] <thekorn> yes will do so in the next days
[20:16] <sectech> Has anyone heard of any bugs trying to run intrepid on vbox?
[20:21] <bahadunn> sectech: by vbox do you mean virtualbox?
[20:22] <sectech> yup
[20:22] <sectech> I tried alpha-2 and the nightly... I get a kernel panic each time
[20:35] <jonpackard> sectech: see bug 246067
[20:36] <jonpackard> 2.6.26-2 and earlier seem to work most of the time
[20:37] <sectech> Kinda hard to triage when you can't install the distro lol
[20:38] <sectech> jonpackard,  Thanks.... I'll tinker around with it a bit later
[20:51] <jonpackard> sectech: DO you have a VT-x or AMD-V capable processor? I've heard that enabling that function in virtualbox sometimes allows a successful boot on the latest Intrepid kernel
[20:56] <sectech> jonpackard, I tried with that option on.... It crawls.
[21:21] <jonpackard> sectech: weird.. isn't that supposed to improve the virtualization performance and compatibility?
[21:25] <bdmurray> nellery: hey there
[21:25] <nellery> bdmurray, hi
[21:26] <bdmurray> Have you seen this debian-bug-search script I wrote?  I think it'd be handy for the bug day
[21:27] <nellery> bdmurray, I believe I saw it on planet
[21:27] <nellery> I'll take a look at it
[21:28] <bdmurray> cool, I thought it might deserve a blip on the targetted bug list
[21:28] <bdmurray> Oh, by the way I usually sort the New bugs by highest number first
[21:28] <bdmurray> So the "fresh" ones are at the top
[21:29] <nellery> bdmurray, woops, I think I forgot to put the dash in -nr
[21:29] <nellery> I probably did --sort:nr
[21:29] <nellery> I'll change that
[21:31] <bdmurray> nellery: cool, thanks!
[21:34] <nellery> no problem
[21:38] <greg-g> ooo, new LP coming out?
[21:51] <jthan_> I just joined Launchpad and the Ubuntu BugSquad, I haven't really gotten into any programming yet but I'm interested in it. How much would I need to know before I begin with a mentor?
[21:54] <Iulian> jthan_: First of all you don't need to know any programming language to work with bugs but if you know it will help you.
[21:54] <jthan_> lulian: what is required then?
[21:55] <jthan_> lulian: I would LIKE to get into programming though, but anywhere is a start.
[21:55] <Iulian> jthan_: Well, just read our wiki page (see the topic). If you have any more questions, feel free to ask here.
[21:55] <Iulian> jthan_: This channel is for Ubuntu bugs only.
[21:57] <Iulian> bdmurray: ping
[21:58] <bdmurray> Iulian: pong
[21:59] <Iulian> bdmurray: Hi there. My membership for bug control team is about to expire in a few days. Could you please renew it?
[22:02] <_gunni_> Is there a possiblity to push a bug? There is a bug, assigned, confirmed, and patch is inside the launpad entries (Just one line of code), but isnt fixed for some time.
[22:05] <Iulian> _gunni_: Which bug?
[22:07] <_gunni_> https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/204624
[22:13] <_gunni_> Iulian: Patch is in this post, just to make it easier: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/204624/comments/11
[22:14] <bdmurray> Iulian: you are all set
[22:32] <bdmurray> ogasawara: any ideas about 21481?
[22:33] <ogasawara> bdmurray: whoa, 2.6.12
[22:33] <bdmurray> eh, I think it has been hijacked
[22:35] <bdmurray> starting around comment 16
[23:54]  * calc hugs the people who wrote the greasemonkey scripts, they rock! :)
[23:56] <bdmurray> ;)
[23:57]  * greg-g needs to remember to update those soon, he's must be broken, because everyone has 0 karma :)
[23:57] <bdmurray> Yeah, I fixed that last week
[23:57] <bdmurray> You might as well wait until after the next roll out though as I suspect some stuff will break again
[23:57] <greg-g> yeah, figured
[23:58] <greg-g> i haven't been doing a ton of triaging lately anyways
[23:59] <sbeattie> bdmurray: did you push your mutt scripts to bzr somewhere?
[23:59] <bdmurray> not yet
[23:59] <bdmurray> sbeattie: is there one in particular you are intereseted in?


[05:25] <ebroder> Whoa...
[05:25]  * ebroder has never seen a Malone: #123 closer before
[05:33] <kaushal> hi
[05:34] <kaushal> which package contains unbuffer command in 8.04
[05:34] <kaushal> I did install expect-dev
[05:34] <kaushal> and also expect
[05:34] <kaushal> when i say unbuffer it says command not found
[05:35] <micahg> kaushal: it's a sample expect script not a binary
[05:35] <kaushal> ok
[05:35] <kaushal> so where do i have to copy it ?
[05:36] <kaushal> so that it becomes available for all users
[05:36] <micahg> kaushal: that's a question for #ubuntu
[05:36] <kaushal> ok
[05:36] <kaushal> micahg: Thanks
[05:36] <ebroder> udienz: ping?
[05:38] <udienz> ebroder: yup
[05:39] <ebroder> udienz: I'm looking at your bug #690927. Do you know anything about how translations work with Debian? (I don't)
[05:40] <udienz> ebroder: not much but little
[05:41] <ebroder> udienz: I'm slightly hesitant to pull in a new translation without any review - I'd be a lot happier if the new translation came in through Debian
[05:42] <micahg> http://i18n.debian.net/l10n-pkg-status/t/tpb.html
[05:42] <udienz> ebroder: hm.. okay, so i must remove po files?
[05:42] <udienz> micahg: thanks
[05:43] <micahg> udienz: I think you just need to file a bug on the BTS with the appropriate tags
[05:44] <ebroder> udienz: http://www.debian.org/doc/developers-reference/l10n.html#l10n-faqtr
[05:44] <ebroder> There's a debian-l18n-indonesian list on lists.debian.org. That would be a good place to look for review
[05:44] <ebroder> I wouldn't mind including the new translation as much if it had been vetted
[05:45] <udienz> micahg: ok i will submitting to debian now
[05:45] <ebroder> udienz: I also have some other comments I'm pulling together; just wanted to see if you were any better informed about Debian's l10n efforts than me before I tried to chase down information
[05:45] <udienz> ebroder: i come from debian-l18n-indonesian
[05:45] <udienz> i'm stuff at debian-l18n-indonesian
[05:45] <ebroder> udienz: ...oh. Well, then :)
[05:46] <micahg> udienz: I was wrong, it's supposed to go through peer review on teh appropriate l10n list before inclusion is requested
[05:49] <udienz> ebroder, micahg: hm.. i take wrong way.. followong developer-reference "As a maintainer, never edit the translations in any way"
[05:49] <ebroder> udienz: That's referring to the package maintainer editing translations they get from the l10n teams
[05:50] <udienz> so if debian-l18n-indonesian submitting via list l10n it can be approved? and we can including it?
[05:51] <udienz> i mean approved bu ubuntu-sponsors
[05:51] <udienz> *by
[05:51] <ebroder> If you submit the translation to debian-l18n-indonesian, and the other people on the list review and approve it, then yeah, I'd have no problem sponsoring it in Ubuntu, with the assumption that it would go directly into Debian (and it would no longer be in our diff) after Debian releases
[05:52] <micahg> udienz: as a general rule, unless there's a rush, it's always better to try to get it in through Debian first
[05:56] <udienz> ebroder: po files has been sended to debian-l18n-indonesian
[05:56] <ebroder> udienz: Great, thanks
[05:56] <udienz> micahg: what the meaning of rush? i mean what conditions to make a package is rush
[06:00] <micahg> udienz: well, it's subjective, if it's not that something's broke, or we're near a freeze, and the Debian maintainer is responsive, the problem is when we make changes in Ubuntu, it requires a developer to review the changes again when Debian updates, so if it's pushed through Debian, it won't require someone here to review it again
[06:03] <udienz> micahg: hm.. ic ic.. understood..
[06:04] <udienz> ok i know, if we make changes and Debian change it we make a ton of job every 6 month
[06:05] <micahg> udienz: right, but that's not to say that we don't take changes, it's just one should think whether or not it can wait for the next Debian version to be released
[06:05] <ebroder> udienz: Or potentially more often than every 6 months, since we like to try and stay in step with any updates Debian releases over the course of our development cycle
[06:07] <udienz> ups sorry i missing not at "Debian change" => Debian bot change it
[06:08] <udienz> *not
[06:55] <dholbach> good morning!
[07:00] <udienz> i have questions
[07:00] <udienz> how to merge changelog?
[07:00] <ebroder> udienz: The easiest way is with bzr merge-package
[07:01] <udienz> ebroder: hm.. and aother way?
[07:02] <ebroder> udienz: Use http://merges.ubuntu.com, which will merge the changelog for you
[07:02] <ebroder> udienz: Or use dpkg-mergechangelogs
[07:02] <micahg> udienz: grab-merge if it's on merges.u.c
[07:02] <udienz> ebroder: yu, i use ./grab-merge.sh for last package
[07:03] <udienz> *yup
[07:04] <udienz> dpkg-mergechangelogs: command not found
[07:05] <udienz> hm.. which package i can get dpkg-mergechangelog command?
[07:05] <ebroder> udienz: http://pastebin.com/qZEirbQS
[07:19] <AnAnt> Hello
[07:20] <AnAnt> fabrice_sp: ping
[07:20] <AnAnt> fabrice_sp: what do you think about syncing luatex 0.65.0-1 & context 2010.07.30-1 from experimental ?
[09:17] <geser> udienz: or "merge-changelog" from ubuntu-dev-tools
[09:19] <udienz> geser; wow thanks! i'm very frustrated while installing dpkg-dev (<IP_ADDRESS>ubuntu3) at lucid
[09:19] <udienz> oke lets me try merge-cgangelog
[09:30] <AnAnt> tumbleweed: ping
[09:38] <AnAnt> tumbleweed: nevermind
[09:51] <Rhonda> cool version string: 4:2.0.3-kde4.4.0really2.0.2-kde4.4.0-0ubuntu1
[09:52] <Rhonda> Actually the package kmldonkey doesn't seem to ever be able to get back into sync state unless the debian maintainer of the package can get convinced to also add the epoch?
[12:08] <ScottK> Once 2.0.4 gets released it can.
[12:22] <Al_1> hi guys. I'm using tkgate and I've noticed a 2yo bug that seems fairly easy to fix upstream https://bugs.launchpad.net/ubuntu/+source/tkgate/+bug/307220 . Can someone fix this? thanks :)
[12:27] <sagaci> dholbach: thanks for the ustream getting started with ubuntu development, you did a good job with explaining why we need each things rather than just setting out to copy/paste commands, however you do need to fix your second slide to read "gpg --gen-key", not "gpg --key-gen" :)
[12:35] <Rhonda> ScottK: No, it can't.
[12:35] <Rhonda> ScottK: That would still leave the 4: epoch in ubuntu and none in Debian - or can a sync cope with that?
[12:35] <ScottK> Oh.
[12:35] <ScottK> I didn't realize Debian had no epoch at all.
[12:35] <ScottK> You're correct.
[12:35]  * Rhonda really wonders why the epoch was introduced in the first place.
[12:35] <ScottK> Sorry for the noise.
[12:36] <Rhonda> And there is no changelog for that version on changelogs.ubuntu.com btw. :)
[12:36] <Rhonda> just the copyright file
[12:37] <hrw> hi
[12:37] <hrw> if package is in -proposed can anyone change verification-needed into verification-done or can it be done only by sru-reviewers team?
[12:38] <hrw> sru-verification team I meant
[12:39] <dholbach> sagaci, ah thanks - will do
[12:40] <dholbach> sagaci, done
[12:56] <hrw> ok, one package verified in -proposed
[13:38] <ari-tczew> sladen: is +nmuX versioning welcome in Ubuntu? I didn't hear. https://launchpad.net/ubuntu/+source/mountall/2.20+nmu1
[13:40] <sladen> ari-tczew: not generally.  But in this case I wanted to sponsor the offered debdiff as-is; normally we'd send that to Debian, but for mountall Ubuntu is upstream
[13:41] <ari-tczew> sladen: then I prefer to use 2.20.1 or similiar
[13:41] <ari-tczew> we have not maintainers for packages in general :)
[13:43] <sladen> ari-tczew: indeed, I repeat.  We don't have maintainers.  It was purely that I wanted to sign the offered debdiff verbatium, and not detract from whatever Debian coaching they are getting just because the upstream happens (for this single package) to be Ubuntu
[13:45] <ari-tczew> sladen: odd, but okay, I'm not an archive admin to rate versioning quality.
[15:02] <den_> ура)...Приветствую всех!
[15:04] <ari-tczew> !english
[15:05] <ari-tczew> !english | den_
[15:13] <den_> oh sorry my english so bad
[15:53] <hrw> question: if rebuild of package is required (no changes) then what is proper procedure? bump version and ask for sponsorship?
[16:34] <ari-tczew> hrw: could be
[16:35] <hrw> thx
[16:35] <geser> hrw: yes
[17:00] <AnAnt> Hello, what is the patch pilot ?
[17:01] <ari-tczew> AnAnt: https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Patch%20Pilots
[17:01] <ari-tczew> maybe ubottu should gain option !patchpilot :>
[17:11] <AnAnt> ari-tczew: thanks
[17:11] <ari-tczew> np
[17:29] <MTecknology> persia: hey.. I was tidying up my system and ran across a script - you might remember me talking about it some and i thought you might be interested in it - http://pastebin.ubuntu.com/544513/
[18:04] <ari-tczew> mr_pouit: what do you think about sync xfswitch-plugin ?
[18:04] <ari-tczew> or merge if necessary
[19:00] <mr_pouit> ari-tczew: useless, gdm3 doesn't exist in ubuntu
[20:28] <micahg> paultag: Do you know about etckeeper?
[20:28] <paultag> micahg: I don't :)
[20:29] <paultag> micahg: let me look into it, thanks :)
[20:29] <paultag> micahg: my git solution is a bit of a kludge ;)
[20:29] <micahg> paultag: ah, that explains, cd /etc; git init :)
[20:29] <paultag> Oh cool! it supports git :)
[20:29] <micahg> paultag: it supports whatever you want :)
[20:29] <paultag> micahg: thanks! That rocks :)
[20:29] <micahg> paultag: just a warning, Debian default is git, Ubuntu default is bzr
[20:30] <paultag> Oh shucks :), well that can be patched around
[20:30] <ari-tczew> is there anybody who can test backported package on maverick?
[20:30] <micahg> paultag: it's a conffile
[20:30] <paultag> micahg: ah, even better :)
[20:31] <micahg> paultag: it also adds hooks to the package manager, so it commits before and after updates
[20:31] <paultag> micahg: what did you think of the rest of the blog post?  I really tried to not joke too far
[20:31] <paultag> micahg: Oh cool!
[20:31] <micahg> well, people are RTing it, I hope they read it as well
[20:32] <paultag> me too :)
[20:41] <udienz> micahg: hello, i have any questions again
[20:41] <udienz> i'm working at bugs 514401
[20:42] <udienz> but from lp:ubuntu/checkbox contain build/ dir
[20:42] <udienz> can i remove it? i think its temporary directory that created from building
[20:43] <micahg> udienz: not sure, the lp:ubuntu/foo branches have the source in it
[20:44] <micahcowan> udienz, that means that the file usr/bin/ssh-keyscan doesn't appear in the foo.install file for any package, which means it won't be placed in any package, and it's an error because dh_install was told (via --fail-missing) to throw an error when that happens.
[20:44] <micahcowan> Sorry, that was directed to the wrong person. :\
[20:45] <udienz> micahg: no no.. no source code, but build directory. chechbox based at python
[20:45] <udienz> micahcowan: no problem :)
[20:47] <micahg> udienz: sorry, I don't know the python build system, but someone should grab it from the sponsors queue and let you know
[20:47] <udienz> ok
[20:48]  * udienz request doko to review, because he is last commiters
[20:49] <micahg> udienz: it's usually best to just get it in the queue and let people review at their leisure unless it's urgent or being ignored
[20:55] <udienz> micahg: can i ask from emails, i can not daily online again for one/two week
[20:56] <micahg> udienz: general questions?
[20:56] <udienz> micahg: yup, maybe usual questions
[20:56] <micahg> udienz: try the MOTU ML
[20:57] <udienz> micahg<EMAIL_ADDRESS>[20:57] <micahg> udienz: yep


[03:32] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [riscv64] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[04:16] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [amd64] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[04:19] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [s390x] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[04:19] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [arm64] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[04:19] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [ppc64el] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[04:25] -queuebot:#ubuntu-release- New binary: libkf5pimcommon [armhf] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[04:39] <RikMills> ubuntu-archive: please accept the libkf5pimcommon new binaries. needed so that the rest of the KDE PIM stack can build
[05:01] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [amd64] (lunar-proposed) [4:22.11.80-0ubuntu1]
[05:01] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [armhf] (lunar-proposed) [4:22.11.80-0ubuntu1]
[05:01] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [riscv64] (lunar-proposed) [4:22.11.80-0ubuntu1]
[05:01] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [arm64] (lunar-proposed) [4:22.11.80-0ubuntu1]
[05:01] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [s390x] (lunar-proposed) [4:22.11.80-0ubuntu1]
[05:01] -queuebot:#ubuntu-release- New: accepted libkf5pimcommon [ppc64el] (lunar-proposed) [4:22.11.80-0ubuntu1]
[05:08] <RikMills> ^ thanks!
[05:27] -queuebot:#ubuntu-release- New binary: pastedeploy [amd64] (lunar-proposed/main) [3.0.1-1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: tepl [amd64] (lunar-proposed/universe) [6.2.0-2] (no packageset)
[05:39] -queuebot:#ubuntu-release- New binary: tepl [ppc64el] (lunar-proposed/universe) [6.2.0-2] (no packageset)
[05:59] -queuebot:#ubuntu-release- New binary: tepl [armhf] (lunar-proposed/universe) [6.2.0-2] (no packageset)
[05:59] -queuebot:#ubuntu-release- New binary: tepl [arm64] (lunar-proposed/universe) [6.2.0-2] (no packageset)
[05:59] -queuebot:#ubuntu-release- New binary: tepl [s390x] (lunar-proposed/universe) [6.2.0-2] (no packageset)
[06:00] -queuebot:#ubuntu-release- New: accepted tepl [arm64] (lunar-proposed) [6.2.0-2]
[06:00] -queuebot:#ubuntu-release- New: accepted tepl [s390x] (lunar-proposed) [6.2.0-2]
[06:00] -queuebot:#ubuntu-release- New: accepted tepl [armhf] (lunar-proposed) [6.2.0-2]
[06:01] -queuebot:#ubuntu-release- New: accepted nut [armhf] (lunar-proposed) [2.8.0-5]
[06:01] -queuebot:#ubuntu-release- New: accepted tepl [amd64] (lunar-proposed) [6.2.0-2]
[06:01] -queuebot:#ubuntu-release- New: accepted pastedeploy [amd64] (lunar-proposed) [3.0.1-1]
[06:01] -queuebot:#ubuntu-release- New: accepted tepl [ppc64el] (lunar-proposed) [6.2.0-2]
[08:32] -queuebot:#ubuntu-release- New binary: kdevelop [amd64] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[08:33] -queuebot:#ubuntu-release- New binary: kdevelop [s390x] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[08:34] -queuebot:#ubuntu-release- New binary: kdevelop [ppc64el] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[09:08] -queuebot:#ubuntu-release- New binary: kdevelop [arm64] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[09:23] -queuebot:#ubuntu-release- New binary: kdevelop [armhf] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[10:47] <sil2100> Okay, since I finally have some time, let me clear out that kinetic-proposed situation. Have no idea why so many packages were left lying around
[11:42] <xnox> rbasak:  we actually need kpatch backports, but the one in kinetic unapproved lacks SRU paperwork, now that kinetic is stable. I guess yes, please reject, and i will reupload them.
[11:45] <rbasak> Done, thanks
[11:45] -queuebot:#ubuntu-release- Unapproved: rejected kpatch [source] (kinetic-proposed) [0.9.7-0ubuntu1]
[12:25] <laney> anyone looked into the oem packageset sync failures that are spamming devel-permissions?
[12:27] <rbasak> I don't see much spam.
[12:27] <rbasak> There's the occasional failure
[12:27] <rbasak> Am I missing more?
[12:28] <rbasak> I mean it'd be nice if spurious failures didn't result in emails
[12:28] <rbasak> But I don't think there are failures happening right now?
[12:46] -queuebot:#ubuntu-release- New binary: kdevelop [riscv64] (lunar-proposed/universe) [4:22.11.80-0ubuntu1] (kubuntu)
[13:06] -queuebot:#ubuntu-release- Unapproved: dotnet6 (kinetic-proposed/universe) [6.0.110-0ubuntu1 => 6.0.111-0ubuntu1~22.10.1] (no packageset)
[13:09] -queuebot:#ubuntu-release- Unapproved: dotnet6 (jammy-proposed/universe) [6.0.110-0ubuntu1~22.04.1 => 6.0.111-0ubuntu1~22.04.1] (no packageset)
[13:14] <laney> Looks like a couple of instances of network trouble this week, hopefully will (or has) self resolve.
[14:53] -queuebot:#ubuntu-release- New source: licheerv-rtl8723ds-dkms (jammy-proposed/primary) [1.0-0ubuntu0.1]
[15:37] -queuebot:#ubuntu-release- Unapproved: u-boot (kinetic-proposed/main) [2022.07+dfsg-1ubuntu4 => 2022.07+dfsg-1ubuntu4.1] (core)
[15:58] -queuebot:#ubuntu-release- New: accepted open3d [amd64] (lunar-proposed) [0.16.0+ds-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted open3d [armhf] (lunar-proposed) [0.16.0+ds-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted open3d [riscv64] (lunar-proposed) [0.16.0+ds-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted open3d [arm64] (lunar-proposed) [0.16.0+ds-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted open3d [s390x] (lunar-proposed) [0.16.0+ds-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted open3d [ppc64el] (lunar-proposed) [0.16.0+ds-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted kdevelop [amd64] (lunar-proposed) [4:22.11.80-0ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted kdevelop [armhf] (lunar-proposed) [4:22.11.80-0ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted kdevelop [riscv64] (lunar-proposed) [4:22.11.80-0ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted rygel [amd64] (lunar-proposed) [0.42.0-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted rygel [armhf] (lunar-proposed) [0.42.0-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted rygel [riscv64] (lunar-proposed) [0.42.0-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted kdevelop [arm64] (lunar-proposed) [4:22.11.80-0ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted kdevelop [s390x] (lunar-proposed) [4:22.11.80-0ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted rygel [ppc64el] (lunar-proposed) [0.42.0-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted kdevelop [ppc64el] (lunar-proposed) [4:22.11.80-0ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted rygel [s390x] (lunar-proposed) [0.42.0-2ubuntu1]
[15:58] -queuebot:#ubuntu-release- New: accepted rygel [arm64] (lunar-proposed) [0.42.0-2ubuntu1]
[17:22] -queuebot:#ubuntu-release- Unapproved: accepted dotnet6 [source] (kinetic-proposed) [6.0.111-0ubuntu1~22.10.1]
[17:45] -queuebot:#ubuntu-release- New: rejected mint-y-icons [sync] (kinetic-proposed) [1.6.1-1]
[17:45] -queuebot:#ubuntu-release- New: rejected passes-gtk [sync] (kinetic-proposed) [0.6-1]
[18:02] -queuebot:#ubuntu-release- New: accepted licheerv-rtl8723ds-dkms [source] (jammy-proposed) [1.0-0ubuntu0.1]
[18:06] <vorlon> doko: any plans to do something with Debian bug #1017666? seeing that it's now two llvm releases behind and uninstallable in sid
[18:06] -ubottu:#ubuntu-release- Debian bug 1017666 in src:amdgcn-tools "amdgcn-tools: Please upgrade to llvm-toolchain-14" [Important, Open] https://bugs.debian.org/1017666
[18:07] <vorlon> doko: oh, perhaps it's not uninstallable in sid; llvm-toolchain-13 is still present in Debian, though perhaps unbuildable due to spirv-llvm-translator removal
[18:07] <vorlon> llvm-spirv [amd64 arm64 armel armhf mips64el mipsel ppc64el s390x] <!stage1> | hello [!i386]
[18:07] <vorlon> what kind of build-dep is that
[18:49] -queuebot:#ubuntu-release- New binary: licheerv-rtl8723ds-dkms [riscv64] (jammy-proposed/universe) [1.0-0ubuntu0.1] (no packageset)
[19:04] -queuebot:#ubuntu-release- New: accepted licheerv-rtl8723ds-dkms [riscv64] (jammy-proposed) [1.0-0ubuntu0.1]
[19:32] -queuebot:#ubuntu-release- Unapproved: isync (jammy-proposed/universe) [1.4.4-3 => 1.4.4-3ubuntu<IP_ADDRESS>] (no packageset)
[19:41] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [source] (kinetic-proposed) [2.06-2ubuntu13]
[19:44] -queuebot:#ubuntu-release- Unapproved: accepted evolution-data-server [source] (kinetic-proposed) [3.46.1-0ubuntu1]
[19:51] -queuebot:#ubuntu-release- Unapproved: accepted evolution [source] (kinetic-proposed) [3.46.1-0ubuntu1]
[19:54] -queuebot:#ubuntu-release- Unapproved: accepted openvswitch [source] (kinetic-proposed) [3.0.1-0ubuntu<IP_ADDRESS>]
[19:58] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (kinetic-proposed/main) [2.06-2ubuntu13 => 2.06-2ubuntu13] (core, i386-whitelist)
[20:03] -queuebot:#ubuntu-release- Unapproved: grub2-unsigned (kinetic-proposed/main) [2.06-2ubuntu13 => 2.06-2ubuntu13] (core, i386-whitelist)
[20:21] -queuebot:#ubuntu-release- New source: python-qpageview (jammy-proposed/primary) [0.6.2-3~ubuntu<IP_ADDRESS>]
[20:25] -queuebot:#ubuntu-release- Unapproved: frescobaldi (jammy-proposed/universe) [3.1.3+ds1-1 => 3.2+ds1-1~ubuntu<IP_ADDRESS>] (no packageset)
[20:38] -queuebot:#ubuntu-release- Unapproved: accepted u-boot-nezha [source] (kinetic-proposed) [2022.04+git20220405.7446a472-0ubuntu<IP_ADDRESS>]
[20:51] -queuebot:#ubuntu-release- Unapproved: accepted u-boot-nezha [source] (jammy-proposed) [2022.04+git20220405.7446a472-0ubuntu0.2]
[21:03] -queuebot:#ubuntu-release- Unapproved: accepted libpfm4 [source] (jammy-proposed) [4.11.1+git32-gd0b85fb-1ubuntu0.1]
[21:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [amd64] (kinetic-proposed) [2.06-2ubuntu13]
[21:04] -queuebot:#ubuntu-release- Unapproved: accepted grub2-unsigned [arm64] (kinetic-proposed) [2.06-2ubuntu13]
[21:07] -queuebot:#ubuntu-release- Unapproved: accepted grub2-signed [source] (kinetic-proposed) [1.186]
[22:56] -queuebot:#ubuntu-release- Unapproved: accepted wike [source] (kinetic-proposed) [1.8.1+ds-1ubuntu1]
[23:02] -queuebot:#ubuntu-release- Unapproved: accepted isync [source] (kinetic-proposed) [1.4.4-3ubuntu<IP_ADDRESS>]
[23:08] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (jammy-proposed/main) [2.765.11 => 2.765.12] (desktop-core, i386-whitelist)
[23:11] -queuebot:#ubuntu-release- Unapproved: rejected plymouth [source] (jammy-proposed) [0.9.5+git20211018-1ubuntu3.1]
[23:13] <tsimonq2> Given Bileto's current issues with copying, what would be the most acceptable way to land the LXQt 1.2 stack currently sitting in that PPA, once it's fully ready?
[23:13] <tsimonq2> I can certainly upload all the source.changes files at once, but that strikes me as wasting builder resources... thoughts?
[23:14] -queuebot:#ubuntu-release- Unapproved: rejected openconnect [source] (jammy-proposed) [8.20-1ubuntu0.1]
[23:26] -queuebot:#ubuntu-release- Unapproved: accepted librm [source] (jammy-proposed) [2.2.2+really2.2.2-0ubuntu0.1]
[23:44] <vorlon> tsimonq2: I'm indifferent to the waste of builder resources; and a major reason I'm broadly down on use of bileto is that test results don't get copied over so it wastes autopkgtest resources, which is certainly a larger concern right now given queue sizes
[23:44] <vorlon> (and there's no way around that today, and autopkgtest costs swamp any builder costs right now)
[23:45] <tsimonq2> Thank you, that exactly answers my question :)


[01:33] <aeoril> I am wanting to start developing for Ubuntu.  I am interested in low level development (like kernel, drivers, modules, etc) but have not developed on Linux in a while.  I am trying to pick an appropriate image to start developing on from cdimage.ubuntu.com.  I found the images for Ubuntu 14.04.1 LTS (Trusty Tahr).  Would that be a good choice?
[10:23] <apw> aeoril, most development goes on at the tip, both kernel and distro wise, so i'd recommend vivid for that use
[11:19] <aeoril> apwx ok, thanks - that is good to know
[11:19] <aeoril> apw ^


[08:07] <tjaalton> someone complains that libdrm in x-updates "broke multiarch"
[08:08] <tjaalton> fails to install both amd/i386 versions
[08:08] <tjaalton> or upgrade in this case
[08:12] <bryce> hrm
[08:13] <tjaalton> which sounds really weird though
[08:13] <tjaalton> it's been M-A: same for ages
[08:14] <bryce> tjaalton, looks like that was a sync from debian git; is it missing some necessary multi arch patch or something?
[08:14] <tjaalton> I'll forward it to ubuntu-x
[08:14] <tjaalton> no, quantal is fine
[08:14] <tjaalton> *it's fine on quantal, no reason why it wouldn't be on precise
[08:14] <tjaalton> unless there's some apt/dpkg bug
[08:14] <tjaalton> unfixed
[08:15] <yofel_> tjaalton: that mail was from me, need some more info?
[08:15] <tjaalton> yofel: ah right
[08:16] <tjaalton> was about to forward it to ubuntu-x@
[08:19] <tjaalton> yofel: anyway, no reason why it wouldn't upgrade just fine
[08:19] <tjaalton> nothing wrong in the package
[08:19] <tjaalton> source package
[08:20] <yofel> well, the only thing I could think of would be gzip putting out different data on i386 and amd64...
[08:20] <tjaalton> yes
[08:38] <yofel> tjaalton: nvm, downloading the debs straight from launchpad installing them with dpkg worked now. Seems like the amd64 deb wasn't downloaded right. (Except that dpkg didn't notice that)
[08:38] <tjaalton> yofel: ah, yeah I think there's a dpkg bug for that
[08:38] <yofel> ok, thanks anyway :)
[08:39] <tjaalton> np
[10:53] <mlankhorst> ok burning a quantal cd
[10:57] <seb128> mlankhorst, waouh, some people still do that in the age of USB sticks? ;-)
[10:57] <mlankhorst> seb128: didn't want to look into how to make a quantal netboot cd..
[11:01] <mlankhorst> I have 4 netboot filesystems for testing instead
[11:16] <mlankhorst> of course simply right clicking iso and hitting burn fails on size estimation..
[11:30] <mlankhorst> oh now it works, might have been failing on my custom kernel
[13:13] <mdeslaur> any ETA on releasing the mesa packages in precise-proposed and oneiric-proposed? We'd like to publish a security update, and are waiting for those two to go to -updates first...
[13:33] <mlankhorst> seb128: well can reproduce it at least, how silly
[13:34] <seb128> mlankhorst, which one? the xrestop issue?
[13:34] <tjaalton> mdeslaur: bryce has been working on the precise update
[13:35] <mlankhorst> nah the quantal crash
[13:35] <mlankhorst> I'll try with valgrind next
[13:35] <seb128> mlankhorst, oh, ok ;-)
[13:35] <tjaalton> what quantal crash?
[13:35] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1065113
[13:36] <tjaalton> ah
[13:41] <tjaalton> mdeslaur: not sure about oneiric
[13:42] <tjaalton> mdeslaur: meh, don't think anyone cares about oneiric anymore, so I guess you can override the current version there and drop the commit
[13:43] <tjaalton> been nearly three months without a verification
[13:45] <mdeslaur> tjaalton: ok, thanks...for precise, I'll wait for bryce to give me an update
[13:55] <mlankhorst> hmmz
[13:56] <mlankhorst> now I have a zero width window for quitting installation
[14:02] <mlankhorst> and other fun
[14:04] <stefan``> hi guys - i'll probably be the 1000s person to annoy you with that
[14:04] <stefan``> ... but any news on bugs 1061073 or 1065125?
[14:06] <mlankhorst> but I did find some suspicious valgrind errors about that, which might explain why it was zero-width too
[16:08] <ScottK> Dear Ubuntu X people: Any suggestions on how to reply to https://lists.ubuntu.com/archives/kubuntu-devel/2012-October/006446.html
[16:09] <tjaalton> try gles
[16:32] <Sarvatt> ScottK, stefan``: was kde-workspace upgrading from 4.9 to 4.9.2 in the same timeframe ruled out? we've had mesa 9.0 snapshots going in for a few months and didn't have any reports of problems also, perhaps testing some of those to locate where the regression introduced might be helpful if it's really recent http://paste.ubuntu.com/1285353/
[16:35] <ScottK> OK.  I'll see if I can find a suitable victim to do the tests.
[16:36] <Sarvatt> shame stefan`` left since he just reported hitting it this morning, darn
[16:42] <Sarvatt> following up on his bug 1061073
[16:46] <tjaalton> well there is the regression in rendering, which doesn't affect unity anymore since it's using gles now
[16:47] <tjaalton> in i915_dri so gen3
[17:22] <bryce> mdeslaur, yeah sorry; the precise update is still on my todo list but had other pressing priorities lately.  Presently it looks like there are some issues which are going to take some work to get resolved.  I don't know the status of what's going into oneiric.
[17:23] <tjaalton> there was one nouveau patch in oneiric-proposed waiting for feedback since mid-july, so probably ok to drop it?
[17:48] <mlankhorst> well yeah :)
[20:35] <ScottK> I have a victim <- <- <- tester.
[20:43] <ScottK> Sarvatt: <StFS> ScottK: ok I'm using 9.0-git20120903 now and it sucks :(. Major artifacts and the desktop effects are very slow.
[20:43] <ScottK> So it's not a recent change.
[20:47] <ScottK> Hello StFS.
[20:47] <ScottK> Sarvatt: StFS has an affected system as well.
[20:47] <StFS> Hi
[20:48] <StFS> Sarvatt: ahh... you're the kind sould who's helping me on my bug on launchpad :)
[20:49] <StFS> I just commented. I installed mesa 9.0 git20120903 and the bug is present there... don't think there's much use in trying out the other two versions you mentioned since it clearly came before the 20120903 version.
[21:23] <mdeslaur> bryce: ok, thanks for the update. I guess we'll ignore it then and just do our update.
[21:24] <ScottK> mdeslaur: Would it make sense to copy the mesa in precise-proposed to -updates and you base off of that?  Except for your comment about the security issue, it's otherwise ready to release.
[21:25] <mdeslaur> ScottK: huh? bryce said there are issues with the package in -proposed
[21:25] <ScottK> Hmm.
[21:25] <ScottK> All the bugs are marked verified.
[21:25] <mdeslaur> ScottK: well, if that's the case, it should get pushed to -updates
[21:26] <ScottK> bryce: Should I remove mesa from precise-proposed so it doesn't get released by accident?
[21:26]  * ScottK waits for bryce.
[21:28] <bryce> ScottK, there are no known user issues.  The problem is that a couple test cases changed behavior.  According to Intel those are test suite issues not indications of user affecting problems
[21:29] <ScottK> So you'd recommend to release it?
[21:29] <bryce> ScottK, I'd have no problem releasing it.  It works fine on the hardware, aside from the piglit irregularities (which would be hard to track down)
[21:29] <ScottK> OK.  Thanks.
[21:30] <tjaalton> then we can push 8.0.5 to proposed after the security update :)
[21:31] <ScottK> bryce and mdeslaur: Done.
[21:35] <mdeslaur> bryce, ScottK: thanks
[22:13] <bryce> thanks
[22:59] <maxb> Really really weird problem on an Asus UX21A ... Pressing Fn+F5 ("brightness down") works as expected but Fn+F6 ("brightness up") when pressed multiple times seems to block until notify-osd has timed out for each level of brightness increased before the next keypress is honoured.... any thoughts? :-)
[23:02] <RAOF> I concur; that's a really weird problem :)
[23:06]  * maxb wonders if this is actually -kernel, -x or -desktop territory :-/
[23:08] <RAOF> Likely to be -desktop territory, I think?
[23:09] <bryce> maxb, there's a Hotkeys page in wiki with some tips on debugging / isolating bugs like that
[23:12]  * maxb goes to read
[23:21] <maxb> I have a sinking feeling that it could be the BIOS being dumb. The events show up delayed in xev
[23:33] <maxb> Aaanyway, looks like it's off to kernel land for me
[23:33] <RAOF> Hi ho, hi ho, it's off to kern'l we go!
[23:49] <bryce> http://www.markshuttleworth.com/archives/1195
[23:49] <bryce> Raring Ringtail
[23:49] <RAOF> Hello Possums! </edna>
[23:51] <bryce> RAOF, don't forget to snag a micro-usb (male) to usb (female) on-the-go adapter, in case you need to connect a keyboard
[23:51] <RAOF> Will do. Thanks.


[13:07] <pjotter> In whiskermenu, the category 'Other' seems to randomly disappear en reappear after a log-out/in. Does anyone know what is causing this?
[22:37] <Unit193> bluesabre: 1. Did you want garcon to have Gir too?  2. Uh...Which packages had something move from one to the other?  exo wasn't it? >_<
[22:41] <bluesabre> Unit193: yeah, that’d be great! Eco had bits move to xfce4-settings
[22:42] <Unit193> So at this point I might as well presume "if it supports it, Sean wants it".  OK.  And thanks!


[04:46] <The_LoudSpeaker> Hey! We at #lubuntu-devel were considering making changes to grub commands during installation of lubuntu so that the nvram entry and the menu entry of grub read "Lubuntu" instead of current "ubuntu". We wanted to know your thoughts on it. TIA
[05:30] <flocculant> infinity: I'm not about much anymore - but still in Xubuntu Release team till the end of the week - just rebooted into new kernel and bug 1824677
[05:30] <ubot5`> bug 1824677 in xserver-xorg-video-nouveau (Ubuntu) "Display only has 640x480" [Undecided,New] https://launchpad.net/bugs/1824677
[09:53] -queuebot:#ubuntu-release- Unapproved: python-django-mptt (disco-proposed/universe) [0.8.5-0.1ubuntu1 => 0.8.7-1] (no packageset) (sync)
[12:05] <mparillo> I am sure it has been discussed, but I like the idea of having flavour-specific grub menu items, for those of us who dual-boot two different flavours.
[12:22] <infinity> tjaalton: Care to poke at LP: #1824677?
[12:22] <ubot5`> Launchpad bug 1824677 in xserver-xorg-video-nouveau (Ubuntu) "Display only has 640x480" [Undecided,Confirmed] https://launchpad.net/bugs/1824677
[12:23] <infinity> mparillo: How does update-grub decide which flavour you have installed when you have kubuntu-desktop, ubuntu-desktop, and lubuntu-desktop all installed?
[12:24] <infinity> mparillo: Which is probably about as common as people who install them in side-by-side partitions.
[12:24] <infinity> (Which is to say, not very common in either case)
[12:30] <tjaalton> infinity: nouveau modeset is now disabled by default, I'll tell him how to enable it..
[12:31] <mparillo> Fair enough. I always dual-booted rather than picking a desktop through SDDM, but as you say, neither is a common use case.
[12:31] <mparillo> I see in my current ISO testing lsb_release -a still says (development branch). I assume that gets removed just before the release is marked, correct?
[12:32] <infinity> mparillo: That will go away with Monday's builds.  But I want weekend testing so maybe we have some things to fix on Monday. :P
[12:33] <infinity> tjaalton: Being thrust back into 1992 suddenly is a bit jarring.  Is that how it's going to go for all nouveau users, or just some small subset of PCI IDs?
[12:34] <tjaalton> infinity: for everyone who haven't installed nvidia blob
[12:34] <infinity> :/
[12:34] <tjaalton> nouveau.modeset=1 re-enables it
[12:34] <infinity> That... Suboptimal.
[12:34] <infinity> s/That/That's/
[12:34] <infinity> What was the motivation for that?
[12:35] <tjaalton> bug 1821820
[12:35] <ubot5`> bug 1821820 in xorg-server (Ubuntu) "Cannot boot or install - have to use nomodeset" [Low,Fix committed] https://launchpad.net/bugs/1821820
[12:35] <mparillo> Thanks infinity. So I will mark my test case as passed for now, expecting a Monday re-spin.
[12:36] <infinity> tjaalton: But that was an Intel bug..
[12:36] <tjaalton> no
[12:36] <tjaalton> someone hijacked it
[12:36] <tjaalton> that bug is what I mentioned on the kernel channe..
[12:37] <tjaalton> l
[12:37] <tjaalton> https://patchwork.freedesktop.org/patch/296411/ needed for some intel
[12:37] <tjaalton> with buggy panels
[12:38] <tjaalton> I discussed the nouveau thing with upstream, and they said the firmware is buggy, and it frequently is
[12:39] <infinity> (someone hijacked what?)
[12:39] <infinity> 1821820 is very much all i915 all the time.
[12:40] <tjaalton> no it isn't, the original reporter has a hybrid machine and nouveau is messing it up
[12:40] <tjaalton> and reported that the new kernel works
[12:40] <infinity> lspci disagrees with you.
[12:41] <tjaalton> haha
[12:41] <tjaalton> ok, wrong bug
[12:41] <tjaalton> hang on
[12:42] <tjaalton> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1822026
[12:42] <ubot5`> Ubuntu bug 1822026 in linux (Ubuntu Disco) "[Dell Precision 7530/5530 with Nvidia Quadro P1000] Live USB freezes or cannot complete install when nouveau driver is loaded (crashing in GP100 code)" [Undecided,Fix released]
[12:42] <infinity> Anyhow, I'm not super happy with a solution that forces everyone down to 640x480.  I don't know what per centage of our install base is nvidia, and what per centage of those use the free driver, but I assume it's a non trivial number of people.
[12:45] <tjaalton> maybe would be better to disable only on "new enough" hw
[12:45] <tjaalton> which require buggy fw
[12:45] <infinity> More problematic, for my inner hippie, is that I feel this is just going to force people to install the non-free driver when they don't need to, since there's no obvious way in the GUI to re-enable modeset.
[12:46] <infinity> Plus, for old GPUs, the non-free driver is a mess.
[12:46] <infinity> I mean, it's not great for new ones either, but at least it's maintained. :P
[12:49] <infinity> I wonder if we could fudge a nouveau modeset "driver" in ubuntu-drivers that just installs a modprobe.d snippet and warns about the potential dangers.
[12:49] <infinity> So users have a choice in the driver panel between free (but maybe buggy) and non-free (but differently buggy).
[12:53] <tjaalton> perhaps
[12:53] <tjaalton> I'll think of how to make this a smaller gun
[12:53] <tjaalton> and limit it to "fresh" hw
[15:41] <flocculant> tjaalton: ta :)
[16:00] <tjaalton> flocculant: for what?
[16:06] <tjaalton> flocculant: oh, got it
[16:31] -queuebot:#ubuntu-release- Unapproved: latte-dock (disco-proposed/universe) [0.8.7-0ubuntu1 => 0.8.8-0ubuntu1] (kubuntu)
[17:27] -queuebot:#ubuntu-release- Unapproved: blis (disco-proposed/universe) [0.5.1-11 => 0.5.2-6] (no packageset) (sync)
[23:07] <xnox> Laney, infinity, do we need more noawait triggers somewhere? Look for "cycle found while processing triggers"
[23:07] <xnox> http://paste.ubuntu.com/p/GPTn3d2Dr4/