[13:29] <mup> Bug #2037727 opened: Temporal migration tries to install btree_gin which already exists <MAAS:New> <https://launchpad.net/bugs/2037727>
[13:35] <mup> Bug #2037727 changed: Temporal migration tries to install btree_gin which already exists <MAAS:New> <https://launchpad.net/bugs/2037727>
[13:38] <mup> Bug #2037727 opened: Temporal migration tries to install btree_gin which already exists <MAAS:New> <https://launchpad.net/bugs/2037727>
[15:38] <mup> Bug #2037475 changed: not able to deploy Mantic via MAAS on ppc64le  <MAAS:Triaged> <The Ubuntu-power-systems project:Confirmed> <https://launchpad.net/bugs/2037475>
[18:44] <mup> Bug #2037752 opened: Compose virsh machine will not accept positive value for cores or RAM <MAAS:New> <https://launchpad.net/bugs/2037752>
[18:50] <mup> Bug #2037752 changed: Compose virsh machine will not accept positive value for cores or RAM <MAAS:New> <https://launchpad.net/bugs/2037752>
[18:59] <mup> Bug #2037752 opened: Compose virsh machine will not accept positive value for cores or RAM <MAAS:New> <https://launchpad.net/bugs/2037752>


[01:01] <OneM_Laptop> So, I'm having a bit of an issue with wifi on a new install of lubuntu 16.04.
[01:02] <tsimonq2> OneM_Laptop: What's the problem? :)
[01:02] <OneM_Laptop> It displays the connecting icon for a couple seconds, then "Disconnected, you are now offline shows".
[01:04] <OneM_Laptop> The wifi dongle I'm using is a bog-standard realtek rtl8188cus type, so if I'm correct, drivers shouldn't be an issue.
[01:04] <OneM_Laptop> Due to the location of the computer, ethernet is not an option for getting it working.
[01:06] <OneM_Laptop> Any ideas?
[01:07] <tsimonq2> !realtek
[01:07] <tsimonq2> idk, the bot is smart XD
[01:07] <tsimonq2> OneM_Laptop: That *might* help ^^^^^
[01:11] <OneM_Laptop> Ok. Thank you!
[05:26] <mahdi> Hi
[05:26] <mahdi> Can I get some help here?
[05:27] <hateball> !ask | mahdi
[05:29] <mahdi> I want to install lubuntu core, minimum installation. I followed this page : https://help.ubuntu.com/community/Lubuntu/Documentation/MinimalInstall   but at the end I ended up with Ubuntu 16.10 fully installed. Can someone help me with that?
[05:30] <mahdi> I downloaded Ubuntu 16.10 "Yakkety Yak" and booted from cd , followed the instructions.
[05:47] <hateball> mahdi: well to begin with, 16.10 is EOL
[05:47] <hateball> mahdi: so use either 16.04 or 17.04
[05:49] <hateball> mahdi: and to get core, you need to download the minimal iso first https://help.ubuntu.com/community/Installation/MinimalCD
[05:49] <hateball> and once that is installed, apt install lubuntu-core
[05:51] <Unit193> I would consider installing the task instead, and Lubuntu desktop doesn't install recommends by default, so may want to consider that too.
[06:37] <Kamilion> Anyone got a copy of UMR 16.04 still around? The site's gone and I can't find any mirrors.
[06:45] <LioneLL> UMR ?
[06:46] <Kamilion> ubuntu-mini-remix.
[07:10] <mahdi> Thanks hateball and Unit193 . about the task you mentioned. can you provide a link?
[07:12] <Kamilion> https://askubuntu.com/a/676469/346554
[07:13] <Kamilion> older xenial images will have a broken tasksel. See https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/1530397 for details.
[07:14] <Kamilion> that's only for alternate installs using d-i though.
[07:15] <Kamilion> the minimal image is considered an alternate install, since it uses d-i and not ubiquity.
[07:15] <Kamilion> d-i is debian-installer.
[07:15] <Kamilion> the text-based installer.
[07:16] <Kamilion> in general, the minimal CD is more for doing netboot style installations where you don't need/want the target machine to grab a 600+MB ISO. IPXE is quite happy to slowly load 55MB into memory, takes a minute or two. 600MB at half a meg a second is going to take twenty minutes to load.
[07:21] <Unit193> Bug 1530397
[07:21]  * Unit193 taps on ubottu.
[07:23] <Kamilion> if all you're looking for is lubuntu-core, you can grab https://github.com/kamilion/kamikazi-core/releases/download/0.9.0-rc6/lubuntu-core-amd64-16.04.iso
[07:23] <Kamilion> generated as part of kamikazi-0.9.0-RC6's build process. https://github.com/kamilion/kamikazi-core/releases/tag/0.9.0-rc6
[07:24] <Kamilion> 580 megs, no apps, media libraries, or physical printer support.
[07:24] <Kamilion> PDF printing is still available. Firefox has been replaced with qupzilla, relying on the existing QT libraries.
[07:25] <Kamilion> if qupzilla and QT are removed, that'll shave another hundred megs off.
[07:25] <Kamilion> but a desktop without a viable browser is kind of... not useful.
[07:26] <Kamilion> guess mahdi isn't paying attention anymore.
[07:34] <mahdi> Thanks Kamilion.
[07:35] <Kamilion> sure.
[07:36] <Kamilion> https://github.com/kamilion/kamikazi-core/tree/master/buildscripts/xenial  02-purgelist through 05-purgelist declare which packages were removed from the ISO.
[07:36] <mahdi> My purpose is to have a minimal linux to run ffmpeg for encoding video. I have thin client with a not much strong processor. So I want to use most of it's strength for encoding process not the os itself.
[07:37] <Kamilion> yep, likewise, Xen prefers a minimal environment.
[07:37] <Kamilion> Not that 980MB is exactly minimal; but it's certainly smaller than an on-disk installation
[07:37] <mahdi> and also this thin client is going to use a power bank to run, so I need to use less energy as I can.
[07:37] <Kamilion> if you really need to remaster the disc image, you can do the same as I did
[07:38] <Kamilion> https://github.com/kamilion/customizer
[07:38] <Kamilion> open it up in customizer, change the packages, repack into an .iso again.
[07:40] <mahdi> Ok thanks again. Can I have your mail address if I needed any help?
[07:41] <Kamilion> it's not listed on https://github.com/kamilion ?
[07:41] <Kamilion> yeah, it's there. Left hand sidebar, under location, above website link.
[07:41] <mahdi> Yep it is
[07:42] <Kamilion> https://launchpad.net/~kamilion has my PGP keys if you sign mail.
[07:42] <mahdi> I need just support for usb webcam and ffmpeg
[07:42] <Kamilion> ... then why are you even bothering with a desktop... or even ubuntu in general?
[07:42] <Kamilion> Shouldn't you use something like alpine or something?
[07:43] <mahdi> What do you propose?
[07:43] <Kamilion> last I knew that's what all the crazy docker container stuff was using for the smallest containers.
[07:43] <Kamilion> https://alpinelinux.org/
[07:44] <mahdi> I'll take a look at it and will be back. Thanks indeed
[07:44] <Kamilion> https://pkgs.alpinelinux.org/packages?name=ffmpeg&branch=&repo=&arch=&maintainer=
[07:44] <Kamilion> usb webcam will be a kernel module, specifically the UVC driver.
[07:46] <Kamilion> http://www.ideasonboard.org/uvc/
[07:46] <Kamilion> Arch's wiki generally has the best dump of data reguarding hardware devices
[07:46] <Kamilion> https://wiki.archlinux.org/index.php/webcam_setup
[07:46] <Kamilion> modprobe uvcvideo should be good enough.
[07:47] <Kamilion> unless it's not a uvc camera, in which case, you're kinda screwed. Better to use something like a raspberry pi in that case, and just hook up the 8 megapixel camera.
[07:48] <mahdi> Raspberry Pi just has 1GB memory. I think i need more than that.
[07:49] <mahdi> so in your opinion which version of alpinelinux I should use?
[07:50] <mahdi> it has standard, extended and ...
[07:50] <Kamilion> huh, I've never had a problem, even with 512MB.
[07:51] <mahdi> encoding to x265 is memory extensive. Is it possible to increase rasperry pi memory?
[07:51] <Kamilion> ... oh. No wonder. H.265 barely has any hardware support.
[07:52] <Kamilion> I invoke the hardware h.264 encoder instead.
[07:52]  * Kamilion shrugs
[07:52] <mahdi> i'm afraid they're pretty expensive
[07:52] <Kamilion> dunno, I've never used alpine.
[07:53] <Kamilion> but yeah, if you're using the CPU to encode h.265, you're stuck on a PC
[07:53] <Kamilion> ARM probably ain't gonna cut it in that kind of power envelope
[07:53] <mahdi> my requirements does not include an HD video
[07:54] <Kamilion> that's straight up Atom/Celeron/APU territory
[07:54] <Kamilion> doesn't matter
[07:54] <Kamilion> any CPU encoding is going to be hell
[07:54] <Kamilion> and it's pretty much only amd64 and armeabi-v7a have optimizations
[07:55] <Kamilion> Everything else just uses the hardware encoder on most embedded system on chip devices.
[07:56] <Kamilion> which limits you to h.264. h.265 doesn't even really give much of an advantage at resolutions below ED (720p) or HD (1080p), it can bitpack a little tighter and bucket data differently. The additional macroblocking defines also help, but they're the primary reason why it's so expensive to encode.
[07:57] <Kamilion> so if you're just streaming 1.3mpix; you might consider using the hardware encoder to save tons of power, especally if you're running off a battery bank, as you say.
[07:57] <Kamilion> The largest of those that I'm aware of is about 20 amphours at 5V; anything beyond that stops being a battery bank and becomes a car jumpstart pack (with free USB port!)
[07:58] <mahdi> I need to encode SD video ( 720x576)
[07:58] <Kamilion> or specificially engineered for a higher voltage like 19V
[07:58] <mahdi> Yes I'm using energizer xp18000 which has 19V output
[07:59] <Kamilion> yeah, that doesn't really have enough pixels in it to really make use of the 64x64 macroblocking that h.265 enables... and you're not really going to see a huge difference between that and h.264's 4x4 macroblocks.
[07:59] <Kamilion> which embedded board are you currently prototyping with?
[08:01] <Kamilion> the closest one I know of that would probably do CPU encoding of h.265 would be the odroid-xu4... http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
[08:01] <mahdi> it's HP T620, it's thin client with dual-core cpu. here is the specs https://www.cnet.com/products/hp-flexible-thin-client-t620-tower-gx-217ga-1-65-ghz-4-gb-8-gb-g4u34uaaba/specs/
[08:01] <Kamilion> oh, it's just a PC.
[08:01] <Kamilion> straight AMD64, with an AMD APU
[08:01] <mahdi> yep
[08:02] <Kamilion> use the AMD Radeon HD 8280E instead of x265
[08:02] <Kamilion> then you can use the opencl encoder.
[08:02] <Kamilion> that alone will save you tons of power.
[08:03] <mahdi> I'm not familiar with opencl, I'll take a look
[08:03] <Kamilion> compute on GPU
[08:04] <mahdi> is it powerfull enogh?
[08:04] <Kamilion> https://github.com/GPUOpen-LibrariesAndSDKs/AMF
[08:04] <Kamilion> there ya go.
[08:04]  * Kamilion points at the top folder in the repository, Thirdparty/ffmpeg/ffmpeg-3.3.1
[08:04] <Kamilion> Version 1.4 of the AMF SDK includes support for the H.265 encoder(HEVC) and bug fixes. Version 1.4.4 has support for FFmpeg 3.3.1.
[08:04] <mahdi> thanks a million. since today you are my hero :-)
[08:05] <Kamilion> that may be a pain in the ass on alpine though
[08:05] <Kamilion> but alpine's standard installation iso is only 100mb
[08:06] <Kamilion> if you're truly *needing* to be tiny, it's probably the answer.
[08:06] <Kamilion> otherwise, you can do what I did for my xen ISO
[08:06] <Kamilion> and use TORAM=Yes
[08:07] <Kamilion> use something like customizer, click the 'Terminal' icon to open a chroot, and you can make any changes you want to the system.
[08:07] <Kamilion> I prefer the ubuntu ecosystem, more specifically, the PPA package archives.
[08:08] <Kamilion> There are tradeoffs in that -- ubuntu's packages are built for compatibility, not performance.
[08:09] <Kamilion> adding your changes to the ISO itself ends up compressing everything using SquashFS.
[08:09] <Kamilion> and the squashfs is what gets copied to memory.
[08:09] <Kamilion> Quite good when all you have is 8GB of flash for storage.
[08:10] <main> hi guys
[08:10] <Kamilion> by the way -- that flash will wear out quite quickly, so I'd avoid writing any video to it.
[08:10] <Kamilion> get 16GB of memory in it and use /tmp religiously
[08:10] <main> I have a problem. I have been running Linux Mint based off Ubuntu 14.04 with LXDE, and everything was okay. Now I tried installing Lubuntu 14.04, and the factual screen resolution is lower than it should be.
[08:10] <Kamilion> SD video clips shouldn't be very large
[08:11] <mahdi> Good informations kamilion, I'm not going to write video on disk
[08:11] <Kamilion> main: which GPU?
[08:11] <mahdi> I'm going to stream it
[08:11] <main> on my older system I have been using the open source RADEON driver version 7.3
[08:11] <main> x1600pro
[08:11] <Kamilion> should be supported by 'radeonhd'
[08:11] <main> i'll try that
[08:11] <Kamilion> that's the open source driver you're already using.
[08:12] <Kamilion> the new one is 'amdgpu' for the R5/R7/R9 class
[08:12] <main> well, my display is 1920x1080, but if I select this resolution, the left and the right side is simply cut off
[08:12] <Kamilion> Are you sure it's 1920x1080?
[08:12] <main> i don't see the start menu, i don't see the time, I don't even see the lxpanel below
[08:12] <Kamilion> That is a pretty uncommon resolution.
[08:12] <main> Kamilion, according to xrandr yes
[08:12] <main> hrm
[08:12] <Kamilion> 1920x1200 or 1600x900 is far more common :/
[08:13] <Kamilion> 16:10, vs 16:9
[08:13] <main> anyway
[08:13] <main> as of now i resorted to setting 1680x1050
[08:13] <main> to at least see most of the video output
[08:13] <Kamilion> what does the display's EDID report as it's maximum resolution? 1080p?
[08:13] <main> however, i don't see the minutes
[08:13] <main> edid?
[08:13] <Kamilion> it should be recorded in /var/log/Xorg.0.log
[08:14] <main> display is okay
[08:14] <Kamilion> it should be recorded in /var/log/Xorg.0.log
[08:14] <mahdi> Thanks again kamilion, I'll do some reading right now.
[08:14] <Kamilion> along with the reason you're not getting your full resolution.
[08:14] <main> it was working fine with linux mint 17.2 (basically ubuntu 14.04) with LXDE
[08:14] <Kamilion> If you're running 16.04, you should probably install the hwe packages
[08:14] <main> > Now I tried installing Lubuntu 14.04
[08:15] <Kamilion> linux-signed-image-generic-hwe-16.04 for the kernel
[08:15] <main> had the same problem with 16.04 and figured i'd go w/ 14.04 to debug it frist
[08:15] <Kamilion> https://github.com/kamilion/kamikazi-core/blob/master/buildscripts/xenial/12-addlist-xwin-hwe-16.04.synpkg
[08:15] <main> i'm not running 16.04...
[08:15] <Kamilion> and here's the list of the hwe packages
[08:15] <Kamilion> Well, 14.04 ain't getting any newer, so if it ain't working, it ain't working.
[08:16] <Kamilion> the only fixes that's ever going to get are security at this point, cause it's so old
[08:16] <main> like I said, it had been working on my older system
[08:16]  * Kamilion nods
[08:16] <main> with my display and GPU
[08:16] <main> that is, on the same hardware
[08:16] <Kamilion> and radeonhd should still support that class of GPU.
[08:16] <Kamilion> so you're going to have to check the log I mentioned for the exact error.
[08:17] <Kamilion> the error will likely be recorded in /var/log/Xorg.0.log
[08:17] <Kamilion> and should probably be a line starting with EE:
[08:18] <main> http://termbin.com/kmea
[08:18] <main> no error
[08:18] <Kamilion> http://puu.sh/xav1N/2984c9c330.png
[08:19] <main> Kamilion, on the Linux Mint system the module version was 7.3
[08:19] <main> not 7.7
[08:19] <Kamilion> the display does report 1080p as a valid mode
[08:19] <main> is there a way to install the 7.3 version to see if it'll work?
[08:20] <Kamilion> sure, install from linux mint's repositories on top of the canonical repositories.
[08:20] <Kamilion> RADEON(0): Output VGA-0 using initial mode 1920x1080 +0+0
[08:21] <main> https://lut.im/TCtYXeJpWP/YCudEhBOrIOOBvFv.png
[08:21] <main> this is what my screen looks like even w/ resolution 1680x1050
[08:21] <main> Kamilion, what'd be the package name?
[08:22] <Kamilion> dunno, never touched mint before.
[08:22] <Kamilion> you'd have to ask them.
[08:22] <main> i don't think they use their own
[08:22] <Kamilion> but they're sitting on top of the canonical repos.
[08:22] <Kamilion> they do.
[08:22] <Kamilion> Anything they provide supercedes the canonical repos
[08:22] <Kamilion> anything they don't provide is pulled from the canonical repos
[08:23] <main> okay, so 7.3 is not in canonical repos anymore, right?
[08:23] <main> https://packages.ubuntu.com/search?keywords=xserver-xorg-video-radeon
[08:23] <Kamilion> no idea. I only concern myself with lubuntu, and currently, I've been too busy to follow lxqt
[08:23] <main> actually
[08:23] <main> it is
[08:24] <main> Kamilion, how do I install this package?
[08:24] <Kamilion> xserver-xorg-video-radeon-hwe-16.04
[08:24] <Kamilion> if you installed off the 16.04.2 ISO
[08:24] <Kamilion> which now uses the -hwe packages by default
[08:25] <Kamilion> otherwise xserver-xorg-video-radeon will probably remove the entire -hwe X stack
[08:25] <Kamilion> what do you mean, how do you install the package?
[08:25] <Kamilion> I type 'wajig install xserver-xorg-video-radeon'
[08:25] <main> another question is
[08:25] <Kamilion> but it's unlikely that you use wajig.
[08:25] <main> why do they list 7.3 on the website
[08:26] <main> whereas Lubuntu 14.04 is shipped w/ 7.7?
[08:26] <main> and apt show shows 7.7 from trusty channel
[08:26] <main> i'm confused
[08:26] <Kamilion> 7.9 is what's installed for me.
[08:26] <Kamilion> xenial's 7.7
[08:26] <Kamilion> trusty's 7.3
[08:27] <main> okay
[08:27] <Kamilion> but trusty's been broken for me a buncha times.
[08:27] <main> i'd like to install the package from trusty
[08:27] <Kamilion> which is why I moved my ISO builds to 16.04
[08:27] <main> how do I go about it?
[08:27] <Kamilion> because of all the work I and others did in 14.10, 15.04, and 15.10
[08:27] <Kamilion> you said you're on 14.04
[08:27] <Kamilion> so... just install it?
[08:28] <main> http://termbin.com/wrrx
[08:28] <Kamilion> I don't quite understand what your question is.
[08:28] <main> it aint that simple :(
[08:28] <main> should I downgrade xorg first?
[08:28] <Kamilion> well, there you go. it says quite explicity, you have held broken packages.
[08:29] <Kamilion> unhold them, or resolve whatever's broken in the transaction.
[08:29] <main> Kamilion, but this is a fresh install. The only software I've installed myself was inxi
[08:30] <Kamilion> never heard of it, sorry
[08:30] <main> it's a python script
[08:30] <main> showing system info
[08:30] <main> couldn't have possibly broken anything
[08:30] <Kamilion> ... system info? What, like, htop?
[08:30] <main> no, like lshw
[08:31] <main> graphics drivers in use etc
[08:31] <Kamilion> huh. I'll have to add that to my builds.
[08:31] <Kamilion> secv
[08:31] <main> well, if you like it. I find it nice
[08:32] <main> http://smxi.org/docs/inxi-man.htm
[08:32] <main> it provides or more exactly aggregates all kinds of troubleshooting info
[08:32] <Kamilion> https://github.com/kamilion/kamikazi-core/commit/506925eca042aadb778b201eee485d2991b39ce5
[08:32] <Kamilion> done.
[08:32] <main> nice!
[08:33] <main> as for dependencies, the build i'm using is half a years old
[08:33] <Kamilion> probably come in handy the few times X doesn't start up straight away
[08:34] <main> think I'd better do a package upgrade first
[08:34] <Kamilion> https://github.com/kamilion/kamikazi-core/releases
[08:34] <Kamilion> feel free to grab the 980MB ISO, slap it on a USB stick, and start up in a week old 16.04 build.
[08:34] <Kamilion> if your screen doesn't come up correctly with either lubuntu-core or kamikazi, chances are something else is wrong.
[08:35] <Kamilion> if everything works, it was a bug somewhere in the X stack, and that becomes a lot easier to track down
[08:35] <main> Kamilion, actually
[08:35] <main> it's not a Lubuntu issue
[08:35] <Kamilion> it is not meant to be installed
[08:35] <main> the same bug occured in Cent OS 6 and Void Linux
[08:35] <Kamilion> i mean, it's the most up to date lubuntu image you'll find currently
[08:36] <main> yeah, i got it
[08:36] <Kamilion> built 8/7/2017
[08:36] <Kamilion> for 16.04, at least... there's 17.10 dailies that are fresher, of course.
[08:36] <main> so I have two ideas: 1) some software is lacking or 2) newer xorg radeon driver doesn't work correctly with my graphics card
[08:37] <Kamilion> could be the latter. Compare the Xorg.0.log between the versions.
[08:37] <Kamilion> or between working/nonworking
[08:37] <Kamilion> probably also ways to increase logging verbosity too
[08:37] <Kamilion> but generally if the local console doesn't work for me, I give up immediately and fall back to using x2go over SSH.
[08:38] <Kamilion> prrrrrrrrrrobably not an option for you.
[08:38] <main> yep, this is why my goal is to install xserver-xorg-video-radeon=1:7.3.0-1ubuntu3
[08:39] <Kamilion> totally acceptable for me, who primarily manages servers with old matrox video adapters... (it's not even advanced enough to be called a GPU -- it's 2D only!)
[08:39] <Kamilion> i'd suggest trying synaptic
[08:39] <Kamilion> it will suggest a transaction if it can figure one out.
[08:39] <Kamilion> aptitude might as well, but I generally find aptitude's interface to be disturbingly annoying
[08:40] <main> apt upgrade is at 60%
[08:40] <main> going to have to wait a bit
[08:41] <Kamilion> generally for the long term service releases, there's point releases generated every so often -- you can also try going back a couple point releases of 14.04 and if you find that resolves the problem, marking the packages as no touchy, then apt dist-upgrade
[08:41] <main> will it upgrade me to 16.04?
[08:42] <main> btw, i'm continuously being prompted with  upgrade to 16.04.03
[08:42] <Kamilion> http://puu.sh/xavCl/908b780d65.png
[08:42] <Kamilion> will what upgrade you to 16.04?
[08:42] <main> apt dist-upgrade
[08:42] <Kamilion> ... what?
[08:42] <Kamilion> no...
[08:42] <Kamilion> lol
[08:43] <Kamilion> dist-upgrade allows 'new dependancies' to be installed, where 'upgrade' does not.
[08:43] <main> i see...
[08:43] <Kamilion> 'do-release-upgrade' is what ... does the release upgrade.
[08:43] <Kamilion> Eg, if inxi gets an update and now requires the 'hddtemp' package
[08:43] <Kamilion> 'upgrade' will not get hddtemp, 'dist-upgrade' will.
[08:44] <Kamilion> it's pretty common for packages in an LTS release to get an update that changes it's dependancies somewhat
[08:44] <Kamilion> RethinkDB is a good example -- it used to depend on libprotobuf9v4, but now depends on libprotobuf9v5.
[08:45] <Kamilion> as both are available
[08:46] <Kamilion> or Customizer, which requires "make PYTHON=python3 PYQT=5" to select Python3 and QT5 instead of python 2.7 and qt4.
[08:47] <Kamilion> both python-pyqt4 and python3-qt5 are available... and annoyingly enough, have different naming schemes. L:)
[08:48] <Kamilion> Currently I'm really focused on finding QT derived apps because I'm moving to LXQT in 18.04, because they fixed the two bugs in lxqt v.10 for 16.04 that annoy the hell out of me
[08:50] <main> aptitude says xserver-xorg-video-radeon-xenial (version 7.7) replaces xserver-xorg-video-radeon
[08:50] <Kamilion> 0.11 is fixed and I suspect 0.12 might appear before 18.04's release, but may or may not make it into the repos before it's ready
[08:50] <main> should I probably remove it?
[08:50] <Kamilion> well, there you go
[08:50] <Kamilion> Dunno
[08:50] <Kamilion> not without synaptic or something having a solution for installation
[08:51] <Kamilion> but that's why you've got 7.7, clearly.
[08:51] <Kamilion> you have -xenial
[08:51] <Kamilion> in 16.04 it's now -hwe *shrug*
[08:51] <Kamilion> so I guess the trend will continue and 18.04 will rename it again... or keep -hwe, I hope.
[08:52] <Kamilion> so i betcha it's broken in 16.04 too -- as you're running the 16.04 packages, backported to 14.04.
[08:53] <Kamilion> there's probably some release note somewhere about how to undo -xenial
[08:54] <main> https://lut.im/5deK0PUpmt/wCVW7iJqLXeW79ir.png
[08:55] <Kamilion> you're probably kinda screwed
[08:55] <Kamilion> https://launchpad.net/ubuntu/trusty/amd64/xserver-xorg/1:7.7+1ubuntu8.1
[08:55] <Kamilion> https://launchpad.net/ubuntu/trusty/amd64/xserver-xorg
[08:56] <Kamilion> the resolve-ALL-the-dependancies package is pointing at all the 7.7 versions
[08:56] <Kamilion> and I'm not seeing a way to differentiate the original 7.3 packages and the -xenial 7.7 packages.
[08:57] <Kamilion> you may have to get an older 14.04 ISO, perhaps .4 or .3 instead of .5
[08:58] <Kamilion> then you can Lock Version http://puu.sh/xavZU/3128e69a39.png before upgrading.
[09:00] <main> no other way?
[09:00] <Kamilion> I don't know.
[09:00] <main> right
[09:00] <main> after all i don't even know if the problem is w/ 7.7
[09:00] <Kamilion> that is the easiest I can think of to get the older 'xserver-xorg' package
[09:00] <main> and if installing 7.3 will help
[09:00] <Kamilion> before it was replaced by 7.7
[09:01] <main> you sure it's .3 not .2 ?
[09:01]  * Kamilion shrugs
[09:01] <Kamilion> it's 2am and I'm not sure of anything at the moment.
[09:02] <main> do you think it's possible to have 7.3 in 16.04?
[09:02] <Kamilion> not exactly fully awake, and I've pretty much tried to block 14.04 from memory
[09:02] <main> or in latest releases?
[09:02] <Kamilion> Sure, absolutely.
[09:02] <Kamilion> launchpad will build any package you give it a .dsc for and drop it in your PPA.
[09:02] <main> nice
[09:03] <Kamilion> https://launchpad.net/~kamilion/+archive/ubuntu/ppa
[09:03] <Kamilion> i do it all the time
[09:03] <Kamilion> only one package was uploade by me
[09:03] <Kamilion> the rest are all some package I needed from a different release (like karmic's copy of firefox 3.6.3)
[09:04] <Kamilion> or a rebuild of a newer package like dc3dd onto an older release
[09:05] <Kamilion> i still have packages published for lucid and maverick.
[09:05] <main> right
[09:05] <main> so you are moving lubuntu to lxqt?
[09:05] <Kamilion> nnnno?
[09:05] <main> nvm
[09:05] <Kamilion> the packages are already available
[09:06] <Kamilion> I'm pretty sure tsimonq2 is the one that keeps pressing 'start build' these daus
[09:06] <Kamilion> *days
[09:06] <Kamilion> but as I said, I don't keep track of lubuntu development anymore. Everything I needed got fixed in 15.10 and I havn't had to yell at anyone about very much recently. ^_^
[09:07] <main> i see
[09:07] <Kamilion> i already have lxqt 0.10 installed (you can see it in my screenshots)
[09:07] <Kamilion> from the PPA
[09:07] <Kamilion> but they don't publish new builds for 16.04 :/
[09:07] <main> how does user experience differ from that of lxde?
[09:08] <Kamilion> uhhh...
[09:08] <Kamilion> i'm not really sure how to answer that.
[09:08] <Kamilion> other than the QT build of pcmanfm missing a couple menu entries and a couple minor bugs like the desktop background not resizing when the monitor resolution is changed, the experience doesn't change at all.
[09:09] <Kamilion> that was sort of the point of it, I thought.
[09:09] <Kamilion> all the same GUI tools, just using QT as the window themeing & rendering engine instead of GTK+
[09:10] <Kamilion> i tweak my theme a little, because lxqt allows a more windows-7 like setup, icons on the taskbar instead of window names...
[09:10] <main> btw
[09:10] <main> is there a way to get leafpad to automatically save unsaved documents?
[09:10] <Kamilion> dunno, I don't use leafpad.
[09:11] <Kamilion> Gedit is generally what I've stuck with, but I'm going to have to find a QT editor I like soon
[09:11] <Kamilion> http://puu.sh/xawjX/8ed11ee53b.png
[09:11] <Kamilion> this is the other annoying bug in lxqt 0.10
[09:11] <main> does gedit have this autosave feature?
[09:11] <Kamilion> when the panel's in icon mode, it carries over even to the windowpicker
[09:12] <main> so you don't lose unsaved data in case the PC freezes
[09:12]  * main downloading .1 :)
[09:13] <Kamilion> http://puu.sh/xawmS/6aaffc31d5.png
[09:13] <Kamilion> I don't see a plugin for that
[09:13] <Kamilion> but I generally would never have that problem anyway since I have the git plugin
[09:13] <Kamilion> and I'm sure you could rig an autosave script from the python console.
[09:14] <Kamilion> oh, crap
[09:14] <Kamilion> never mind
[09:14] <Kamilion> http://puu.sh/xawp0/8ec3da05d5.png
[09:14] <Kamilion> it's built in... lol
[09:14] <Kamilion> I'm so used to everything being a plugin, I almost forgot to check the other panes
[09:14] <main> nice
[09:15] <Kamilion> i also find it amusing that you are worried about the exact thing my ISO enforces
[09:15] <main> which is?
[09:15] <main> gedit instead of leafpad?
[09:15] <Kamilion> making sure everything gets destroyed on shutdown (inherent quality, since / is in RAM)
[09:15] <Kamilion> everything dies. That's why it's named kamikazi...
[09:16] <Kamilion> not even /var/log is persistant.
[09:16] <Kamilion> (if you wanted persistant logging, you would have told rsyslog to send logs elsewhere!)
[09:18] <Kamilion> internet's fulla bad privacy these days. Lots of VPN providers say "we don't log anything". Court can't subpoena what never landed on 'physical storage'... heh heh. Their own fault for using specific wording in the laws...
[09:19] <Kamilion> I honestly havn't had problems with unreliable hardware in.... years.
[09:20] <Kamilion> and I've seen kamikazi survive system level events that would level most other linux hosts... Things like the PCI Express bus going away entirely and coming back, including EVERY device like AHCI, mpt2sas, uhci, ehci, xhci, everything.
[09:20] <Kamilion> worst I get is a bunch of kernel log entries as the devices are redetected...
[09:21] <Kamilion> having the disk controller suddenly go away would generally trash most linux installations.
[09:22] <main> yeah
[09:22] <Kamilion> or at the very least cause a lot of complaints on the next boot, about unclean mounting, journal replays, and the normal recovery-after-powerfailure behavior
[09:22] <main> so, should I lock anything 7.7?
[09:22] <main> or just xserver-xorg-video-radeon?
[09:23] <Kamilion> locking version on any package will prevent apt from doing anything that would effect that package
[09:23] <Kamilion> so in theory you should get the same error you got earlier
[09:23] <main> so i just lock this one package and that's it, right?
[09:24] <Kamilion> about unable to fix broken packages
[09:24] <Kamilion> yeah.
[09:24] <Kamilion> that should lock the whole chain that relies on it
[09:24] <Kamilion> and I'm pretty sure it won't even apply any security updates to X while in the locked state.
[09:25] <Kamilion> not that something like that happens with any regularity.
[09:30] <main> okay
[09:30] <main> installing .1
[09:30] <main> wish me luck
[09:30] <main> :)
[11:45] <korisnik> good day
[13:49] <sam____> hi
[13:50] <sam____> i want to ask about user name and password
[13:51] <sam____> when i install Lubuntu imege
[14:13] <leszek> just ask


[18:14] <mwharris> cjwatson: can you pull the precise install from proposed (to fix bug #1315462)?
[18:15]  * antarus waves at mwharris
[18:16]  * mwharris waves to the guy behind antarus
[18:24] <xnox> cjwatson: bug #1275162 (grub2 NVMe support for 14.04.1) is now verified. all is good. Busy network bug #1314134 is still verification needed (part of the same upload)
[18:48] <cjwatson> mwharris: nope, needs a bunch of stuff to be verified first, bug 833994, bug 1135163, bug 1172101
[18:48] <cjwatson> xnox: cool, thanks


[12:32] <pygi> seb128, well, and do some changes to packaging ofcourse so it would play nice with FF and other browsers
[12:33] <seb128> pygi: I think you will get an uvf easily for 0.5.2
[12:33] <pygi> seb128, indeed =)
[12:33] <pygi> but it has to be done today :P
[12:34] <pygi> (if I'm not wrong today is the last day for NEW packages)
[12:36] <pygi> asac, you still alive? :)
[12:37] <pygi> seb128, asac : ok, good night now :) Asac, I'll poke during the day, hopefully we can get something done :)
[01:01] <Kopfgeldjaeger> gn8
[02:14] <geser> mathiaz: Hi, are you going to merge fetchmail? the last Debian upload fixes CVE-2007-4565. I guess keescook would be happy.
[02:17] <mathiaz> geser: not in the immediate time. You wanna do it ?
[02:18] <geser> I will do it then.
[02:18] <ion_> Avahi 0.6.21: This is an important bugfix release.
[02:18] <mathiaz> geser: excellent! - Thanks.
[03:10] <bathym> some ubuntu official devel in security hand?
[03:10] <keescook> bathym: I think I want to say "yes".
[03:11] <LaserJock> heh
[03:12] <bathym> ^^
[03:12] <bathym> i search him :P
[03:13] <keescook> bathym: what's up?
[03:14] <ajmitch> keescook: are you sure you want to admit to that?
[03:14] <bathym> query, if it`s possible
[03:14] <keescook> bathym: go ahead and ask.  :)
[03:42] <bathym> Nafallo: ping
[04:34] <lifeless> bryce: if you are around, I have a question about CRT displays and laptops
[04:35] <bryce> lifeless, about to head to dinner actually, but can try to answer if it's a quickie
[04:35] <lifeless> ok.
[04:35] <lifeless> basically, fn-F8 doesn't seem to work in X on my dell d430
[04:36] <bryce> yup
[04:36] <lifeless> which has a 945
[04:36] <lifeless> is this likely to be fixed before release, or is there a test driver I can grab?
[04:36] <lifeless> I have a presentation to give tonight ;)
[04:37] <bryce> upstream marked it "won't fix" actually, so there's no fix available
[04:38] <bryce> mjg59 might be able to explain it better, but as I understand it the issue is that acpi is not passing along the key combo correctly
[04:43] <mjg59> Dells don't send acpi events for that
[04:43] <mjg59> There needs to be something in userspace listening for the correct key
[04:43] <lifeless> sadness
[04:44] <lifeless> is someone working on this? Is there anything trivial I can do other than subscribing to the bug (which # is it  ?)
[04:44] <bryce> lifeless: 'rez' in launchpad is the tester at dell who has reported many of these previously
[04:45] <bryce> same issue happens with dell + nvidia
[04:45] <lifeless> what would be lovely is if plugin the monitor, then it just works as xinerama or something
[04:45] <kylem> lifeless, just mash it manually with xrandr.
[04:45] <lifeless> but thats a different discussion
[04:46] <lifeless> kylem: oh lovely, 1.2 is here isn't it
[04:46] <kylem> if you're on 945.
[04:46] <bryce> lifeless: yeah I'm hoping for hungry hippo we can put some work into that
[04:47] <ajmitch> kylem: is there hope for us on older intel chips (i915)?
[04:47] <kylem> yes, just use -intel...
[04:48] <bryce> kylem: btw, did you get a chance to put the discover-data upload in?  I noticed I'd listed 'feisty' in the changelog and uploaded a fixed version
[04:48] <ajmitch> useful, no doubt it's better than last time I used it, when it broke compiz :)
[04:48] <kylem> not yet. was going to leave it until tomorrow. guess i can do it now.
[04:48] <bryce> no hurry
[04:48] <bryce> ok, getting called to dinner.  bbl
[04:55] <mjg59> bryce: We discussed this in London
[04:55] <mjg59> bryce: The solution is pretty straightforward, but it needs some code adding to gnome-settings-daemon
[04:58] <lifeless> kylem: thanks
[04:58] <kylem> no problemo.
[04:59] <lifeless> kylem: xrandr --auto is love
[04:59] <kylem> lifeless, lol.
[05:00] <lifeless> I like things that just work.
[05:00] <lifeless> :)
[05:24] <LongPointyStick> pkern_: it means you need to see !uvf, and file an exception for anything you want synced.
[05:24] <LongPointyStick> i *wish* kmos would stop giving out wrong information.
[05:25] <ajmitch> heh
[05:31] <ajmitch> what's he presenting?
[05:33] <RAOF> How to write fast python
[05:34] <ajmitch> interesting
[05:34] <RAOF> Indeed.
[05:35] <RAOF> Hence the 'looking forward to it' :)
[05:35] <ScottK> Step 1: Get someone other than ScottK to write it.
[05:35] <bddebian> haha
[05:37] <lifeless> huh
[06:21] <jml> RAOF: when/where's this presentation?
[06:21] <RAOF> jml: SLUG, this evening.
[06:22] <jml> RAOF: man I wish I could live in a city.
[06:24] <RAOF> Heh
[06:25] <ajmitch> hobart not enough of a city?
[06:26] <LaserJock> city? who wants a city?
[06:26] <ajmitch> jml: come on, I'm in dunedin :)
[06:27] <Amaranth> RAOF: record it
[06:36] <lifeless> jml: come to sydney then
[06:37] <lifeless> it will be recorded anyway I expect by the slug av folk
[06:37] <jml> lifeless: I'll look out for it.
[07:04] <sponix> can I gripe here ?
[07:05] <nixternal> nope
[07:06] <nixternal> this is a development channel, griping won't get you far around here
[07:07] <LaserJock> sponix: maybe a bug report might work?
[07:07] <sponix> apt-get install vsftpd <enter> "The following packages will be REMOVED:  gadmintools gproftpd proftpd proftpd-mysql proftpd-pgsql"
[07:07] <sponix> why can you have 5 flavors of web server installed, but only one ftp daemon flavor ?
[07:07] <sponix> is it against the law to run proftpd on 65534 and vsftpd on inet port 21 ?
[07:08] <LaserJock> sponix: must be the dependencies
[07:08] <sponix> vsftpd has _no_ deps
[07:09] <infinity> No, all ftp daemons conflict.
[07:09] <sponix> minus glibc
[07:09] <infinity> As do all MTAs.
[07:09] <infinity> Etc.
[07:09] <nixternal> yup
[07:09] <sponix> but now webservers ?
[07:09] <RAOF> No, for some reason.
[07:09] <sponix> s/now/not/
[07:09] <infinity> http daemons are the odd one out here, due to many requests to allow multiples (for things like using lighttpd to server static content and apache to serve dynamic)
[07:10] <infinity> s/server/serve/
[07:10] <sponix> how do I give it the "force-it-you-biatch" flag, to keep it from nuking my other pkg while installing ?
[07:10] <sponix> well, vsftpd for anon && proftpd for pr0n !
[07:10] <infinity> proftpd does anon quite well too...
[07:10] <infinity> And does vhosting...
[07:10] <RAOF> You'd pull the source package, remove the conflicts:, and rebuild.
[07:10] <infinity> Not sure why anyone would really want more.
[07:10] <sponix> infinity:  I know, but vsftpd is a bit lighter for that
[07:11] <infinity> But, yes, you could rebuild one of the source packages to not Provide and Conflict ftp-server.
[07:11] <infinity> sponix: If proftpd is already running anyway, I'm not sure what's heavy about having it bind to two ports and have it serve anon on one.
[07:11] <sponix> hmm, apt-get build-dep vsftpd ?
[07:11] <infinity> Seems heavier to run two daemons.
[07:11] <RAOF> apt-get source vsftpd
[07:12] <sponix> infinity:  because its not what I _want_ *Grin*... Thats what t3H LuNiX is all about, it does what I fsck'n want it to
[07:13] <sponix> I still wonder why aptitude exist in the first place
[07:13] <RAOF> Because it's your one-stop apt shop.
[07:13] <infinity> sponix: Ahh, but it only does exactly what you want if you build it yourself, really.
[07:13] <sponix> ls
[07:13] <sponix> ha.. oops :P
[07:14] <sponix> when I suck it down with that apt-get source vsftpd does it apply the patches, or do I need to do that ?
[07:14] <nixternal> you need to apply the patches
[07:14] <sponix> Duh, it says it .. never mind
[07:14] <RAOF> nixternal: What??
[07:14] <infinity> See, and I just realised which "not a support channel" channel we're in, too.
[07:15] <sponix> nixternal:  sorry... it says that it applied the diff
[07:15] <nixternal> oh, the diff..I was thinking debian/patches..sorry
[07:15] <sponix> infinity:  yeah... I appreciate the help, and I'm sorry to take away from devel for my petty prefs ;)
[07:16] <sponix> RAOF:  good idea... thanks for the help
[07:16] <RAOF> sponix: https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff?highlight=%28debdiff%29 minus the debdiff part should do.
[07:17] <infinity> sponix: apt-get install devscripts fakeroot ; apt-get source vsftpd ; apt-get build-dep vsftpd ; sed -i -e 's/ftp-server//g' vsftpd-*/debian/control; (cd vsftptd-* && dch -i && dpkg-buildpackage -rfakeroot -uc -us -b)
[07:17] <sponix> RAOF:  RTFM ! *Grin*
[07:17] <infinity> sponix: There.  Now we can stop talking about it.
[07:20] <sponix> infinity:  that was above and beyond the call of duty. Especially since you think I'm a tard for wanting multiples ... Thanks a ton though
[07:21] <infinity> sponix: Don't feel too bad, I think everyone's a "tard"... There's a reason they don't let me lurk in support channels.
[07:21] <beuno> the parameter could be called 'args' inside the method as it is in the
[07:21] <beuno> caller and have a better docstring.  I can fix that and merge it if
[07:21] <sponix> aye, how long as the Redhat cluster suite be in the repos ?
[07:21] <beuno> er, wrong window  :D
[07:22] <infinity> sponix: Since before dapper.
[07:22] <sponix> just noticed it yesterday
[07:22] <StevenK> infinity: libnss-db!
[07:22] <sponix> Now if they just port the AD && coolkey stuff I'll be all set
[07:25] <infinity> StevenK: Never heard of it.
[07:27] <StevenK> infinity: Hmph
[07:28] <infinity> StevenK: I'll clear that off my TODO tonight.
[07:29] <infinity> StevenK: I've got a lull in OMG URGENT stuff, finally.
[07:30] <StevenK> infinity: *nods* Just want a "Okay, looks fine." or a "Uh, this is broken." and I'll fix it or upload it.
[07:32] <Chipzz> infinity: actually, devscripts is (knowingly) missing a dependency on some perl package for dch to work properly (as an aside ;))
[07:40] <YokoZar_> Which is correct for a control file:  libncurses5-dev | libncurses-dev [i386]   or  libncurses5-dev [i386]  | libncurses-dev [i386]   -- I want neither on non i386
[07:42] <infinity> YokoZar_: The latter.
[07:42] <YokoZar_> infinity: thanks
[09:04] <siretart> iwj: sure. btw, the comment in the 2nd hunk of debian/rules is a bit confusing. The cryptsetup binary isn't statically linked, is it?
[09:08] <Tonio_> hi
[09:13] <soren> noah__: Thank you very much!
[10:01] <TomaszD> does anyone know why the translations for xdg-user-dirs are not picked up at all?
[10:10] <pkern_> LongPointyStick: I thought uvf is for new upstream revisions and not Debian revisions?
[10:29] <asisak> ArneGoetje: I was told you might help me to handle bug 119588. It is not pressing at all, but I look for someone who can take care of this eventually.
[10:29] <ubotu> Launchpad bug 119588 in ubuntu "Wrong rendering of Arabic characters" [Medium,Incomplete]  https://launchpad.net/bugs/119588
[10:34] <ArneGoetje> asisak: I'll have a look
[10:34] <asisak> Thanks, ArneGoetje. Feel free to assign the bug to the right person.
[11:00] <seb128> ion_: hi, do you get bug #135650, could you try to get a valgrind log?
[11:00] <ubotu> Launchpad bug 135650 in gimp "GIMP crashes when trying to resize an image." [Medium,Incomplete]  https://launchpad.net/bugs/135650
[11:37] <iwj> siretart: You're right, that comment is confusing.  It's statically linked _against libcryptsetup_ but dynamically against external libraries.
[12:02] <ArneGoetje> iwj: could you please review https://wiki.ubuntu.com/MainInclusionReportLibhangul for me? Thanks. :)
[12:10] <iwj> ArneGoetje: Sure.
[12:33] <siretart> iwj: I can confirm that your test package didn't blow up my system. (but I don't have crypted root, "only" crypted /home)
[12:36] <iwj> siretart: That's a very helpful report, thanks.
[12:37] <iwj> I think with another quick test here I should be able to upload it.
[12:43] <ulaas> would like to report a scsi problem with gutsy tribe5 alternate install. this should be the right place, correct?
[12:43] <Amaranth> ulaas: http://bugs.launchpad.net/ubuntu
[12:48] <Ng> is the output of the scripts in /etc/acpi/ sent anywhere when, for example, sending&resuming?
[12:50] <seb128> Riddell: is that ok to upate icon-naming-utils to 0.8.6? The new version fixes some icon themes we have at the moment
[12:51] <soren> Ng: There's a bit in /var/lib/acpi-support ?
[12:51] <soren> Ng: What are you looking for specifically?
[12:52] <Ng> soren: hoping for some output of vbetool post, because it hangs quite a bit atm in gutsy for me
[12:53] <soren> Ng: Don't think that's stored anywhere. You can disable the vbetool stuff in /etc/default/acpi-support, though.
[12:53] <Riddell> seb128: sure
[12:54] <seb128> Riddell: thanks
[12:55] <Ng> soren: I need to post the card or I don't get the backlight, but sometimes it hangs and eats CPU (LP #134868)
[12:55] <ubotu> Launchpad bug 134868 in vbetool "100% cpu on resume" [Undecided,New]  https://launchpad.net/bugs/134868
[12:55] <iwj> ArneGoetje: Approved, thanks.
[12:55] <Ng> soren: but I can add some more debugging myself I guess :)
[12:55] <Kopfgeldjaeger> ho
[12:56] <soren> Ng: Ah, I see.
[12:57] <soren> Ng: It doesn't happen on my X40, FWIW.
[12:57] <soren> Ng: Ah.. I have tweaked it, though.
[12:57] <Ng> soren: it never happened to me in feisty and vbetool is the same version in gutsy
[12:57] <soren> Ng: I've set it to do doubel console switching.
[12:58] <Ng> soren: I've enabled that this morning to see if it helps, but I'd never needed it before. in feisty the acpi stuff on this machine was 99% reliable, certainly moreso than windows
[12:58] <soren> Ng: Did you use the -intel driver in Feisty, too?
[12:59] <Ng> soren: yes, the i810 didn't like resuming very much, I found
[12:59] <Ng> +driver
[01:00] <soren> Ng: Ok... I don't remember if I enabled the double console switching already back then, actually.
[01:00] <soren> Ng: Feisty was fine for me with i810.
[01:01] <Ng> soren: 8086:3582 for your graphics chip?
[01:02] <soren> Ng: Yup.
[01:15] <iwj> ogra: I have to say that reworking this cryptsetup main inclusion report hasn't given me a very good feeling about any similar reports from the same author in the future.  I've found a couple more falsehoods in it and it doesn't really seem like the package was investigated during the preparation of the original report.
[01:24] <ogra> iwj, well, that was a very old one, done with the old copy and paste habit, sorry for that
[01:25] <ulaas> zul, u around?
[01:28] <iwj> ogra: I don't think "the old copy and paste habit" is and excuse for multiple false statements, really.
[01:28] <iwj> s/and/an
[01:28] <ulaas> if anyone is interested about bug 127872 . i have a system with the same bug/scscichipset. and have time to get debug info from installer?
[01:28] <ubotu> Launchpad bug 127872 in linux-source-2.6.22 "scsi drives not detected " [Undecided,Incomplete]  https://launchpad.net/bugs/127872
[01:28] <ogra> iwj, what are the fals statements ? i have the first iteration of the doc open ...
[01:28] <iwj> That there are no binaries running as root, for example.
[01:29] <ogra> (there are not many statements at all)
[01:29] <ogra> ah
[01:30] <iwj> I don't know what the Debian BTS looked like when you wrote the report but by now I wouldn't say that "maintainence in Debian is good" without further qualification.  If you look at the Debian BTS and at LP it's clear the package has some "issues".
[01:31] <ogra> well, form an update pov its well maintained
[01:31] <iwj> I just wanted to point out that the next time I read a review from the same author I might treat the assertions in it with a bit more scepticism than I would hope would be necessary.
[01:32] <iwj> And because of that I have to do more work myself and it may not always be at the top of the queue.
[01:32] <ogra> and i see two oustanding bugs marked as important and one in pending upload
[01:32] <iwj> Did you read the one about the data loss ?
[01:33] <ogra> no, at least there is no bugtitle indication something like that anywhere
[01:35] <iwj> 428288
[01:35] <ogra> and i would expect such a bug to be tagged important, which it obviously isnt
[01:35] <iwj> My point is that if I can't rely on the report author to have done the research then I have to do it myself.  That's not really the role of the approver, for obvious reasons.
[01:36] <ogra> right
[01:36] <iwj> So next time I will expect you to understand why perhaps your report doesn't go straight to the top of the list.
[01:36] <ogra> i'll try to be more careful with future reports ... this was actually one i added really from the template since i had discussed it in person with pitti before
[01:37] <iwj> As I said just ^ up there, copying text from the template is no excuse for inclusion of false statements.  The one about no binaries running as root is a cut-and-dried example.
[01:37] <ogra> you will very likely get a new moodle report from me for gutsy if the edu team gets the package ready
[01:38] <ogra> i'll try to make that as good as i can ;)
[01:38] <iwj> Now if it were just that one little slip in an otherwise thorough review then I wouldn't be so bothered but that's not the case.
[01:38] <ogra> well, that was the report you started to change the policy for ...
[01:38] <ogra> and i didnt touch it after you rejected it ...
[01:39] <iwj> Are you asserting that the previous policy was to encourage the inclusion of false statements in MIRs ?!
[01:39] <ogra> no, but it made it easy to let one statement slip through
[01:39] <cjwatson> surely we have had this discussion about MIR policy at length before, and established that Ian was just making it clearer
[01:39] <ogra> which cant happen witrh the new tmplate
[01:39] <iwj> Well I think that as the review author you ought to take responsibility for that.
[01:40] <ogra> cjwatson, right, and that was actually the last MIR i wrote personally
[01:40] <ogra> iwj, i will do that if i write my next one
[01:41] <iwj> I see, well, I hope you'll forgive me if I still take a somewhat sceptical approach to the next one.
[01:41] <ogra> iwj, no, i actually appreciate that, simply as a selfcontrol mechanism :)
[01:42] <iwj> Thanks.
[01:47] <seb128> mjg59: bug ##136346 for you probably
[01:47] <seb128> bug #136346
[01:47] <ubotu> Launchpad bug 136346 in gnome-power-manager "gutsy: g-p-m 2.19.6-0ubuntu4 breaks brightness control" [Undecided,New]  https://launchpad.net/bugs/136346
[01:57] <iwj> cjwatson: So I think I've finished rewriting this review report but I was wondering if you would like to quickly look over the report and give me a second opinion ?   My view is that we probably ought to include it despite the fact that it does have some problems.
[01:57] <iwj> cjwatson: https://wiki.ubuntu.com/MainInclusionReportCryptsetup is the wiki page.
[02:10] <cjwatson> iwj: looking
[02:58] <EtienneG> hey guys
[02:58] <EtienneG> 6.06.2 is advertised as being due today, 2007-08-31
[02:58] <cjwatson> EtienneG: where? we changed that
[02:58] <EtienneG> I have not heard much about it ... just curious if we are going to make it
[02:58] <cjwatson> pushed to next month
[02:58] <EtienneG> cjwatson, https://launchpad.net/ubuntu/+milestone/ubuntu-6.06.2
[02:58] <cjwatson> I'll correct that, thanks
[02:59] <cjwatson> (as soon as I dig up the new date)
[02:59] <EtienneG> cjwatson, thanks, would like to know the new date
[03:00] <cjwatson> EtienneG: https://wiki.canonical.com/Ubuntu6.06.2
[03:00] <cjwatson> ha, it's a bit out of sync though
[03:01] <EtienneG> cjwatson, thanks a lot !  who's the release manager for that one ?
[03:01] <cjwatson> fixed
[03:01] <cjwatson> pitti
[03:01] <Fujitsu> Yay, secret documents.
[03:01] <cjwatson> (on holiday atm)
[03:01] <cjwatson> Fujitsu: the date in the public URL noted by EtienneG is up to date now
[03:02] <Fujitsu> Ah, good.
[03:02] <cjwatson> the full list is private at the moment because an awful lot of the drivers for the specifics of 6.06.2 are Canonical partners of one kind or another
[03:03] <EtienneG> cjwatson, sorry for bugging you during your holiday.  Not get away from the computer !!!  :)
[03:03] <EtienneG> s/Not/Now/
[03:03] <cjwatson> EtienneG: I'm not on holiday; pitti is
[03:04] <EtienneG> cjwatson, ok, sorry then!
[03:04] <EtienneG> he is having a well-deserved one
[03:07] <Chipzz> cjwatson: got a second to look at https://bugs.launchpad.net/ubuntu/+source/vim/+bug/125247 ? should be just applying :)
[03:07] <ubotu> Launchpad bug 125247 in vim "Apache config files in /etc/apache2/sites-available and /etc/apache2/sites-enabled do not alwyas have proper syntax highlighting" [Undecided,Triaged]
[03:07] <cjwatson> Chipzz: sorry, no; I think somebody else has touched-it-last-maintainership of vim by now ;-)
[03:08] <Hobbsee> :)
[03:24] <soren> Chipzz: That would be me.. :/
[03:25] <soren> Chipzz: Oh, but I'm not core-dev. :)
[03:25] <Chipzz> soren: not important really, but is an easy fix, and it didn't get triaged yet though
[03:27] <Mirv> mjg59: hi, vbetool / libx86 debug output has now been going for ca. 7 hours, and the log file is 100MB. just because I don't know anything about instruction dumping works, is it sure other processes don't matter? ie. it only logs whatever the vbetool is doing? I'll let it be probably for this evening and night still.
[03:30] <mjg59> Mirv: Ok, once it's got that big it's /probably/ ok to stop it
[03:30] <mjg59> But yes, it'll only dump what vbetool is doing
[03:34] <Mirv> I'm yearning for the crash to happen :)
[03:35] <mjg59> Could you gzip what it's done so far and attach that to the bug?
[03:36] <kleinernik> hi, i want to help with bugfixing, i found a bug on lunchpad and i think i have got a patch to fix this bug. i uploaded this patch to lunchpad. it is not an important bug, but for me it is a good starting point. can anyone help me, i don't know what to do next, i.e. how to find someone to prove my fix and point out what are the next steps ..
[03:39] <Hobbsee> kleinernik: you might want to see https://wiki.ubuntu.com/MOTU/Contributing
[03:40] <kleinernik> Hobbsee: thank you
[03:42] <mjg59> Mirv: Though, ideally, it would be better if we could wait for it to actually crash, yeah
[03:49] <soren> Could someone please upload http://people.ubuntu.com/~soren/upload/dovecot/ for me?
[03:50] <seb128> Hobbsee, soren: does the goocanvas exception is also granted for pygoocanvas? ;)
[03:50] <Hobbsee> seb128: yes
[03:51] <zul> soren: sure
[03:52] <zul> soren: its ok to upload this one?
[03:52] <seb128> Hobbsee: thanks
[03:58] <iwj> cjwatson: Did you have an opinion about cryptsetup ?  If you're too busy I can ask someone else or just go ahead based on my own opinion.
[04:04] <cjwatson> iwj: whoops, sorry. I think it's reasonable for promotion with your changes. Could you file a bug against partman-crypto to note that it needs to forbid mounting a partition that needs cryptsetup on /usr, though?
[04:04] <StevenK> cjwatson: Since cryptsetup actually lives in /usr?
[04:05] <cjwatson> iwj: what are we doing about things like bug 105394?
[04:05] <ubotu> Launchpad bug 105394 in cryptsetup "Upstart needs some key pressed to show "Enter Passphrase" on boot /  cryptsetup problem" [Undecided,New]  https://launchpad.net/bugs/105394
[04:05] <cjwatson> StevenK: libraries it uses apparently
[04:05] <StevenK> cjwatson: Which is fair enough. Avoiding chicken and egg problems is good.
[04:06] <cjwatson> iwj: bug 90914 has a patch which looks perhaps helpful in part
[04:06] <ubotu> Launchpad bug 90914 in cryptsetup "initramfs cryptroot usplash support" [Undecided,Incomplete]  https://launchpad.net/bugs/90914
[04:07] <seb128> Riddell: how do I get flash non free being used by konqueror?
[04:07] <Riddell> seb128: settings->configure konqueror->plugins->scan for new plugins
[04:08] <Riddell> assuming you have it installed somewhere it's searching
[04:08] <Riddell> although it should do that on startup anyyway
[04:08] <seb128> utch
[04:08] <Riddell> oh, it does it at KDE startup, which I guess means not for you
[04:08] <seb128> 5 Configure items in the settings menu, KDE is impressive :p
[04:08] <Riddell> horrific isn't it
[04:09] <Riddell> one day I'll fix that
[04:09] <seb128> no plugins in the configure konqueror
[04:12] <StevenK> cjwatson: Shouldn't the patch use usplash_write if $count -gt 3 at the end instead of just echo'ing?
[04:15] <iwj> cjwatson: 105394> I don't think we're doing anything about it :-/.  I haven't tested that setup myself but I imagine one response would be `use luks' although of course we don't know if luks is affected too.
[04:16] <iwj> cjwatson: 90914> Yes, perhaps.
[04:16] <seb128> Riddell: flash works fine in konqueror for me
[04:16] <iwj> cjwatson: I think really the package needs some maintenance in Ubuntu but the question is really whether to put it in main now.
[04:16] <Riddell> seb128: with the current gtk or a patched one?
[04:16] <seb128> Riddell: current gutsy
[04:16] <seb128> I was trying to get the bug to fix it
[04:16] <seb128> but not way
[04:17] <Riddell> seb128: oh, that'll be our patch we added which adds a dependency on gtk
[04:17] <iwj> cjwatson: I think I'll call myself the maintainer of the package but I don't propose to fix it up very much for gutsy.  It really needs rather more invasive changes which ought to be done earlier in a cycle.
[04:17] <seb128> Riddell: oh, you did use the workaround?
[04:17] <iwj> cjwatson: So, err, thanks.
[04:17] <Riddell> seb128: for now, but obviously I'd much rather have a workaround in gtk than have konqueror depend on gtk and do the workaround for it
[04:18] <Riddell> seb128: you'll need to downgrade to 4:3.5.7-1ubuntu15 or earlier, or just use opera
[04:21] <iwj> cjwatson: partman-crypto> bug 136382
[04:21] <ubotu> Launchpad bug 136382 in partman-crypto "disallow encrypted separate /usr" [Undecided,New]  https://launchpad.net/bugs/136382
[04:27] <Riddell> asac: any idea what bug 136376 is all about?
[04:27] <ubotu> Launchpad bug 136376 in flashplugin-nonfree "automatic update for mozilla-flashplayer make using flashplayer impossible" [Undecided,New]  https://launchpad.net/bugs/136376
[04:28] <gnomefreak> ok here is good too ;)
[04:32] <Hobbsee> Mithrandir: could you give back krusader on all arches, please?
[04:34] <Mithrandir> Hobbsee: given-back
[04:34] <Hobbsee> Mithrandir: thankyou :)
[04:34] <asac> Riddell: looks like the alternative is no installed for firefox
[04:36] <StevenK> Mithrandir: libzzip-0-12 and libzeroc-ice-cil can be NBS'd out of the archive at your leisure.
[04:37] <StevenK> infinity: Ping, you said tonight.
[04:38] <Mithrandir> StevenK: I'm on too bad a line to want to do any non-urgent archive work, but thanks\.
[04:38] <Mithrandir> s/\\//
[04:38] <StevenK> Mithrandir: Meh, whenever
[04:39] <Mithrandir> yeah, sorry. :-/
[04:39] <Mithrandir> just being on the wrong side of the atlantic.  It's not as bad as being in .au, but getting there.
[04:40] <StevenK> You're helping, Mithrandir, really.
[04:40] <StevenK> :-P
[04:48] <bddebian> Heya
[04:52] <asac_the_2nd> Riddell: ok on amd64 its completely broken... the alternative just points to the wrong file ... e.g. the 32-bit one.
[04:54] <StevenK> Mithrandir: Have you got a sec to poke at kxdocker?
[04:54] <Hobbsee> StevenK: what about it?
[04:54] <Hobbsee> StevenK: it's gone, isnt it?
[04:54] <Mithrandir> StevenK: what kind of poking?
[04:54] <StevenK> It's marked superseded
[04:54] <StevenK> But what about kxdocker-data?
[04:54] <Hobbsee> StevenK: it's been removed, iirc
[04:54] <Hobbsee> that should have been gotten in the removal request
[04:55] <Hobbsee> hmm, seems its' a separate source
[04:55] <StevenK> Yup.
[04:55] <StevenK> But so it has.
[04:55] <StevenK> Mithrandir: Do you want a bug to kill kxdocker-data?
[04:55] <Hobbsee> seb might be able to do it, he's on a more stable connection
[04:57] <Mithrandir> StevenK: please, or just get seb to do it.
[04:57] <seb128> StevenK: it needs removal?
[04:58] <Hobbsee> seb128: yes
[04:58] <seb128> rational?
[04:58] <Hobbsee> seb128: "because i said so"
[04:58] <seb128> Hobbsee: well, just a small rational for the removal text would be nice
[04:58] <StevenK> seb128: It's data files for kxdocker, which was killed before and has been broken since Edgy
[04:58] <Hobbsee> seb128: there's one, right there :P
[04:58] <seb128> like superceded, or not maintained upstream, or ..
[04:59] <Hobbsee> seb128: because kxdocker got removed to brokenness, and someone forgot to ask for removal of both
[05:00] <seb128> Hobbsee, StevenK: removed
[05:00] <Hobbsee> thanks
[05:01] <Hobbsee> seb128: really, "because i said so" is a perfectly valid reason...
[05:01] <bddebian> Hell have no fury....
[05:01] <StevenK> Actually, it's 'hath'
[05:01] <seb128> Hobbsee: right, double checking doesn't hurt though and I like to do things because I agree and not because I've been told to do them ;)
[05:01] <bddebian> I know..   I'm south of you.
[05:11] <nixternal> haha
[05:11] <nixternal> ya, you have about a 1.5 hour lead time on baltimore silly :)
[05:11] <ScottK> About two hours driving in good traffic depending on where in Philly and how close.
[05:11] <bddebian> Well I'm an hour or more NW of Philly
[05:11] <nixternal> oh ya, I forgot turnpike traffic is nuts around philly
[05:12] <nixternal> but I prefer philly turnpike traffic over nyc turnpike traffic
[05:12] <Hobbsee> Mithrandir: something tells me you'd be a little too wounded to do that
[05:12] <bddebian> It's soo close I'd like to go but I have no idea what I'd bring to the table so I dunno..
[05:12] <Riddell> asac: I don't know, I could be wrong on that
[05:12] <asac> Riddell: honestly, I can't get much our of that bug report ... when was the last flashplugin roll-out we did?
[05:13] <nixternal> haha, Mithrandir is trying to recreate the Boston Tea Party with a barrel of LongPointyStick
[05:13] <nixternal> :p
[05:13] <Mithrandir> indeed.  The Ubuntu Tea Party will be great.
[05:13] <nixternal> hahaha, nice
[05:14] <asac> Riddell: he claims that he just received an update ... i don't understand that ... maybe he is talking about something different? some third party extension?
[05:14] <bddebian> Not nearly enough caffeine in Tea for nixternal
[05:14] <nixternal> nope, need a couple of starbucks red eyes for me
[05:17] <StevenK> seb128: Do you mind also killing libapache-mod-lisp; Apache 1.x only, Debian bug #431034
[05:17] <ubotu> Debian bug 431034 in ftp.debian.org "RM: libapache-mod-lisp -- ROM; obsolete; FTBFS" [Normal,Open]  http://bugs.debian.org/431034
[05:17] <bddebian> StevenK: File a bug ya lazy bum.. ;-P
[05:18] <StevenK> bddebian: Hmph
[05:18] <seb128> StevenK: done
[05:19] <StevenK> seb128: Danke
[05:21] <Riddell> asac: nothing very recent according to https://launchpad.net/ubuntu/+source/flashplugin-nonfree
[05:21] <Riddell> asac: I've no idea what the mozilla-flash is he's talking about
[05:23] <asac> yeah ... his description is just confusing and just guesswork. Lets wait for his answer.
[05:24] <Hobbsee> should make asac do it, instead of me.
[05:24] <asac> huh?
[05:25] <asac> Hobbsee: i think you are perfect for that :)
[05:25] <Hobbsee> asac: behind motu interviews.  yo ushould do one
[05:25] <Hobbsee> asac: bah.  i manage to have far too high a profile, even without doing interviews.
[05:29] <Hobbsee> asac: besides, what i'm wokring on keeps changing
[05:38] <bddebian> Hobbsee: Well that's better than working on nothing like me :-)
[05:40] <asac> bddebian: i have some work ... fix flashplugin-nonfree package for real :)
[05:40] <bddebian> What's wrong with it?
[05:40] <asac> well ubuntu5 - which you sponsored ;) - caused some mess ... now that i looked at it i saw that it messed up the target path of the amd64 alternative
[05:41] <gnomefreak> bddebian: might be better to ask what isnt wrong with it
[05:41] <asac> in ubuntu4 it pointed to the npwrapper.libflashplugin.so file in /var/lib/...
[05:41] <asac> now it points to the 32-bit binaries
[05:42] <asac> but i am not sure if the regression slipped in in ubuntu5 ... might have slipped in later as we are already at ubuntu8 :)
[05:42] <bryce> mjg59: I must have not been in the discussion in London about the font sizes (or my memory is failing me).  Was someone going to be adding the code to gnome-settings-daemon?
[05:42] <bddebian> Egads
[05:42] <seb128> bryce: what code?
[05:42] <bryce> seb128: don't know, mjg59 referred to adding some code
[05:43] <mjg59> bryce: Sorry, no, not the font sizes
[05:43] <mjg59> bryce: The display hotkey stuff
[05:43] <bryce> ahh, yes
[05:43] <mjg59> Something needs to catch the keycode and run xrandr --auto
[05:43] <Amaranth> oh, this was the bug filed against metacity and compiz and assigned to seb128
[05:44] <bddebian> I don't have an amd64 though.  Wanna send me one to test with? :-)
[05:44] <bryce> ok I do remember that.
[05:44] <Amaranth> if someone adds it to metacity we can add it to the integration stuff so compiz gets it too
[05:44] <seb128> bryce, mjg59: it's on my list of changes, I'll do it next week
[05:44] <bryce> awesome
[05:44] <gnomefreak> bddebian: i tried that excuse already ;)
[05:44] <bddebian> heh
[05:44] <mjg59> I suspect it makes more sense in gnome-settings-daemon than metacity/compiz
[05:44] <Amaranth> mjg59: true
[05:44] <seb128> yes
[05:45] <bryce> btw, things are looking fairly good for including the latest -ati, which has xrandr 1.2 support and theoretically could enable hotplug projectors for all ati cards
[05:45] <mjg59> bryce: The font size issue is separate. The server is caluclating DPI information now, which GTK is using. Sadly, it seems to be somewhat insane stuff.
[05:45] <mjg59> bryce: I suspect that hardcoding it to 100 would do
[05:45] <bryce> however in testing we've been finding a few regressions, so doing this change is not going to be without some pain.  However upstream is actively developing so I'm hoping the issues will gain fixes soonish
[05:46] <seb128> mjg59: it used to be set to 96 dpi and I think we will do that again for gutsy
[05:46] <bryce> mjg59: yes that's what seb128 and I decided to do.  don't know if the change is in yet
[05:46] <mjg59> Ok, 96 should work
[05:46] <seb128> bryce: no, will do that next week as well
[05:47] <bryce> seb128: ah excellent
[05:48] <bryce> Amaranth: btw, we're switching the default driver from intel hardware from -i810 to -intel soonish; the one major bug we know of is that Xv video playback in compiz is horked (sometimes?) with -intel.
[05:49] <Amaranth> bryce: it's always broken
[05:49] <bryce> however it sounds like Xv playback on -i810 is anyway, and it's more likely we'll see a fix for -intel than -i810
[05:49] <bryce> s/anyway/iffy anyway/
[05:49] <Amaranth> bryce: if i had to guess i'd say totem is picking the first offered xv output which is the textured video one but that only works with exa
[05:49] <Amaranth> but i don't own intel hardware so i can't test
[05:50] <Amaranth> it'd be stupid for the driver to offer it if it doesn't work
[05:50] <bryce> if you have patches or solutions in need of a test, I got one of the dell intel laptops I could run tests on
[05:51] <Amaranth> someone with intel hardware should check in gstreamer-properties to see what Xv 'devices' are offered
[05:52] <Amaranth> i don't know how to query for the info directly, i suppose xvinfo
[05:52] <mjg59> Yes, the first channel will be textured video
[05:52] <mjg59> 965 has no hardware overlay
[05:52] <Amaranth> xvinfo | grep Adaptor
[05:52] <mjg59> So compiz = no xv on 965 on xaa
[05:52] <Amaranth> mjg59: so we have to use Exa?
[05:52] <Ng>   Adaptor #0: "Intel(R) Video Overlay"
[05:52] <mjg59> "have"
[05:52] <Ng> 855GM
[05:53] <Amaranth> Ng: right, you're fine
[05:53] <mjg59> But if you want a composited desktop, yes
[05:53] <mjg59> 855 has no textured video
[05:53] <Ng> I don't use compiz, but I want -intel to be default very much :)
[05:53] <Amaranth> it's apparently only on the 965 since it only does textured video
[05:53] <mjg59> 915 and 945 have textured and overlay, with textured by default
[05:53] <mjg59> 965 only has textured
[05:54] <Amaranth> mjg59: shouldn't the driver just claim to not support any xv adaptors if exa isn't enabled?
[05:54] <mjg59> Amaranth: No, because it works fine if you're not using composite
[05:54] <Ng> mjg59: can I bug you about vbetool, or should I go after someone else? :)
[05:54] <bryce> my machine's only a 845GM, but here's xvinfo and lspci for it:  http://people.ubuntu.com/~bryce/tmp/
[05:54] <Amaranth> mjg59: how?
[05:54] <mjg59> Ng: YOu can try
[05:54] <mjg59> Amaranth: ?
[05:54] <mjg59> Textured video doesn't require exa
[05:54] <Ng> mjg59: it seems to be the same version as in feisty, but my X40 is now failing to resume a fair amount, with vbetool eating all the CPU
[05:55] <bryce> that's without compiz running, I don't know if that makes a difference for xvinfo
[05:55] <Amaranth> mjg59: I was told the textured video output required exa no matter what
[05:55] <mjg59> Amaranth: No
[05:55] <Amaranth> bryce: it doesn't
[05:55] <Amaranth> isn't Exa really...broken?
[05:55] <mjg59> If you mean "Is EXA ready for deployment", I suspect not
[05:55] <bryce> er, that should be 945GM not 845GM.  coffee hasn't reached my fingers yet apparently
[05:56] <Amaranth> bryce: do you get the bug?
[05:56] <Amaranth> bryce: from what mjg59 has said only 965 users should have this problem
[05:56] <bryce> hmm, let me check
[05:56] <bddebian> asac: BTW is flashplugin the one that you yelled at me for because it's in bzr?
[05:56] <Ng> mjg59: (134868 in LP. More than happy to do more debugging if I can)
[05:56] <Amaranth> i wish we could just default to the gl output in gstreamer :)
[05:56] <mjg59> Amaranth: ? No.
[05:56] <mjg59> Amaranth: Textured video is the default in 915 and 945
[05:56] <bryce> I don't recall seeing it, but I can check again
[05:56] <Amaranth> whee
[05:57] <mjg59> 16:53 < mjg59> 915 and 945 have textured and overlay, with textured by default
[05:57] <Amaranth> Drivers are always so messed up :/
[05:57] <Amaranth> hrm
[05:58] <Amaranth> i suppose we could add a gdk_screen_is_composited check or something to totem to tell it to use a different video output
[05:58] <Amaranth> i think totem can override the gstreamer default, anyway
[05:58] <mjg59> Still leaves 965 broken
[05:58] <Amaranth> why?
[05:58] <mjg59> Because it has no overlay hardware
[05:59] <Amaranth> i meant to tell it to use the non-xv sink
[05:59] <mjg59> Oh. No, we can't do that.
[05:59] <mjg59> Performance would be dire.
[05:59] <mjg59> You wouldn't get any hardware scaling
[05:59] <Amaranth> ok then, the gl sink
[05:59] <bryce> yup, I definitely can reproduce the bug here
[06:00] <bryce> tried on the Experience_ubuntu.ogg video and got a blank screen in totem.  Same with a ripped dvd movie
[06:00] <mjg59> Amaranth: I suspect that that won't work well either
[06:00] <Amaranth> oh, but that's in universe
[06:00] <Amaranth> bryce: blank screen is different
[06:00] <mjg59> I mean, I could say "Compiz is not ready for production use" again
[06:00] <Amaranth> bryce: you should get a crash
[06:00] <bryce> Amaranth: ah
[06:00] <bryce> no, no crash
[06:00] <Amaranth> i could have sworn mvo fixed the bug you seem to have
[06:01] <Amaranth> mjg59: i hate drivers :P
[06:01] <Ng> while you're talking about 3d stuff and intel chipsets - after a suspend/resume, all 3d textures on my 855GM are replaced with noise (so if you're using compiz, every window is entirely made of random noise)
[06:01] <Amaranth> apparently no one knew how horrible the new nvidia driver was before switching to it
[06:01] <Ng> (soren confirms seeing it on his too, fwiw)
[06:01] <bryce> this laptop is a few days out of date, so if it's a recent fix that may be why.  I'll update and check again
[06:01] <Hobbsee> night all
[06:02] <Amaranth> we could always use Xgl... :D
[06:03] <asac> bddebian: no
[06:03] <asac> bddebian: maybe gnash?
[06:04] <bddebian> Oh maybe
[06:04] <bddebian> I break so many things it's hard to keep track :-)
[06:04] <bryce>  -> breakfast.  bbiab
[06:04] <asac> hehe
[06:20] <ooo>  /server -m irc.master-online.org:12000
[06:26] <Amaranth> grr
[06:48] <doko> After unpacking 58.2MB disk space will be freed.
[06:48] <doko> Do you want to continue [Y/n] ?
[06:48] <doko> Bus error
[06:48] <doko> (Reading database ... 25795 files and directories currently installed.)
[06:49] <doko> iwj: ^^^ on sparc, this is a dselect-upgrade, continues ok after the bus error. which program is it that fails with the bus error?
[06:50] <iwj> Boggle.
[06:50] <iwj> This is dselect's apt method ?
[06:50] <iwj> Or apt's dselect method, or something ?
[06:50] <iwj> I don't know what that message is from.
[06:54] <ion_> seb128: Yeah, ive been fighting with gimps internal functionality that catches crashes and prints stack traces. I just cant seem to turn it off. Because of that, apport doesnt detect the crashes and using gdb is difficult. gimp --stack-trace-mode=never doesnt seem to work.
[06:55] <ion_> seb128: Almost all dialogs do crash without G_SLICE=always-malloc.
[07:36] <ArneGoetje> doko: sun-java6 deppends on libstdc++5, which is not in gutsy anymore. So, the packages are uninstallable.
[07:37] <cjwatson> libstdc++5 | 1:3.3.6-15ubuntu2 |         gutsy | amd64, i386, powerpc
[07:37] <doko> ArneGoetje: it should be, in universe
[07:37] <cjwatson> not even, it's still in main
[07:38] <doko> hrm
[07:40] <ArneGoetje> not on the taiwan mirror, it seems
[07:40] <ArneGoetje> my aptitude cannot find it
[07:48] <ArneGoetje> ok, found it.
[07:48] <mjg59> What's responsible for determining which types of block device to automount now?
[07:48] <ArneGoetje> seems the '++' needs to be escaped when searching for the package name...
[07:55] <ArneGoetje> doko: do you know which releases use sun-java5 ? the fonts entries there need to be fixed too, I suppose. (except the font packages on older systems have other configurations...)
[07:56] <doko> ArneGoetje: back to dapper, but I can add different versions of this file for every release if needed
[07:57] <alex-weej> doko: last week, you sync'd pyopengl from debian unstable. problem is that the version is 3.0 alpha, and i'm getting pretty bad performance out of it. :(
[07:58] <ArneGoetje> doko: uh... that means I have to try out every release since dapper...
[07:58] <doko> alex-weej: well, at least it works with python2.5. what are the problems?
[07:59] <doko> ArneGoetje: well, dapper and gutsy should be sufficient
[07:59] <alex-weej> doko: i don't know specifically because i don't have any python opengl benchmarks :(
[07:59] <alex-weej> doko: does 2.0.1 not work with python 2.5?
[07:59] <alex-weej> https://bugs.launchpad.net/bugs/135736
[07:59] <ubotu> Launchpad bug 135736 in pyopengl "Serious performance regression from recent update from 2.0.1 to 3.0" [Undecided,New]
[08:00] <alex-weej> fwiw, there is an upstream stable 2.0.2 iirc
[08:00] <alex-weej> oh wait
[08:01] <alex-weej> maybe it isn't alpha after all :( i must have gotten confused :$
[08:02] <LaserJock> oh wow, python 3.0a1 is out
[08:04] <alex-weej> doko: does 3.0.0a6 mean alpha-6?
[08:07] <doko> alex-weej: I wouldn't mind 2.0.2, but this has to be checked on amd64, not just i386
[08:08] <alex-weej> doko: 2.0.2 isn't stable, i was wrong.
[08:09] <alex-weej> doko: also it is only with one specific game (i don't have any other pyopengl apps to test)
[08:09] <alex-weej> but it is consistent across r300 and fglrx on i386
[08:12] <alex-weej> doko: how difficult is it to get APT to downgrade a package anyway? if it's easy i guess it's not release critical
[08:14] <bryce> alex-weej: often it's as simple as just specifying the version.  E.g.:
[08:14] <bryce> apt-get install xserver-xorg-core=2:<IP_ADDRESS>.dfsg-4ubuntu
[08:14] <alex-weej> bryce: i mean automatically
[08:15] <alex-weej> for "the masses"
[08:15] <bryce> ah, nfc
[08:15] <alex-weej> nfc?
[08:15] <bryce> no friggin clue ;-)
[08:15] <bryce> good question tho
[08:16] <doko> alex-weej: either add an epoch (not recommended when debian doesn't do it), or have something like: 3.0.0a6really2.0.1...
[08:16] <alex-weej> heh :E
[08:16] <broonie> In other words, apt will never downgrade without explicit user intervention.
[08:17] <bryce> oh yeah, epochs
[08:17] <doko> Source: qt-x11-free
[08:17] <doko> Version: 3:3.3.8really3.3.7-0ubuntu9
[08:17] <bryce> *shudder*
[08:17] <azeem> there should be multi-level epochs
[08:18] <LaserJock> heh
[08:18] <LaserJock> that sounds fun
[08:19] <alex-weej> doko: so what should i do?
[08:19] <alex-weej> doko: try to find someone on amd64 and see if they get it too?
[08:19] <doko> yes, that would be best
[08:20] <alex-weej> anyone here? :P
[08:33] <bddebian> doko: Is kaffe supposed to include a /usr/lib/kaffe/include dir?
[08:34] <doko> bddebian: I have no idea about kaffe
[08:35] <bddebian> Damn, OK, sorry
[08:35] <bddebian> Hmm, maybe the includes should come from gcj
[08:40] <bddebian> Weird, there is a /usr/lib/kaffe/pthread/include which is a symlink to ../include but that dir doesn't exist
[08:41] <bddebian> POS
[08:43] <bddebian> Ahh, it's in the -dev package
[08:44] <bddebian> Heh, nice build-deps
[09:03] <bddebian> Any archive admins still aboot?
[09:04] <yatiohi> Hello
[09:05] <yatiohi> can i install somehow pthread man pages?
[09:05] <yatiohi> i m new to ubuntu :)
[09:05] <ScottK> yatiohi: #ubuntu is for help.
[09:06] <yatiohi> oh, sorry :)
[09:06] <norsetto> !support | yatiohi
[09:06] <ubotu> yatiohi: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
[09:45] <ion_> Could someone please take a look at bug #136439? I reported it and another person set its status to invalid. In my opinion, he didnt understand what im saying and set the status to invalid based on his misunderstanding.
[09:45] <ubotu> Launchpad bug 136439 in gimp "--stack-trace-mode doesnt seem to work" [Undecided,Invalid]  https://launchpad.net/bugs/136439
[09:53] <DoctorMO> hello everyone
[09:53] <DoctorMO> is this a good place to talk about ideas for Hardy Heron?
[09:55] <LaserJock> DoctorMO: probably not so much
[09:55] <DoctorMO> LaserJock: drat
[09:55] <LaserJock> DoctorMO: we're still focused on Gutsy Gibbon
[09:55] <LaserJock> DoctorMO: best thing I can think of is to do a proposal on ubuntu-devel-discuss or something
[09:55] <LaserJock> writing up a wiki page spec is also helpful
[09:56] <LaserJock> if it's it's more than trivial
[09:56] <DoctorMO> LaserJock: yea, always a case. more than trivial; trivial changes I would impliment and bypass going up stream etc
[10:01] <geser> ion_: have you tried to talk to pedro_ about it?
[10:04] <ion_> In the bug discussion, yes. In IRC, no.
[10:05] <maxamillion> i recently heard that there is a need for a pypanel hacker for ubun2 and i was sent here from #ubuntu-artwork to ask ... is there any validity to this or was i mis-informed?
[10:16] <decriptor> anyone in here working on XEN
[10:16] <decriptor> or is there no future for XEN in ubuntu
[10:18] <kitche> decriptor, looks to me Xen works fine in ubuntu
[10:18] <decriptor> without having to bootstrap
[10:18] <decriptor> it
[10:19] <decriptor> other distros have some xen stuff on the cd so that you can install it as a paravirtualized guest right off the cd
[10:19] <decriptor> suse seems to be the only one that does this well
[10:19] <decriptor> with fedora  the only install option is netowrk
[10:19] <decriptor> ubuntu its you have to bootstrap it
[10:21] <decriptor> I'm kind of guessing that ubuntu isn't going to seriously support XEN?    more support pushed towards KVM?
[10:26] <LaserJock> decriptor: XEN is a  big thing for Ubuntu
[10:26] <LaserJock> we just need people of course
[10:26] <decriptor> ah
[10:27] <decriptor> LaserJock: just finding it really hard to find anyone interested in it
[10:27] <LaserJock> well, that's the nature of the beast
[10:27] <decriptor> suse seems to have the heaviest develop right
[10:28] <decriptor> so I'm wondering if others aren't working on it much and moving towards KVM
[10:28] <LaserJock> they can also pay people to work on it
[10:28] <kitche> decriptor, of course Xen is big with Novell
[10:28] <decriptor> does that mean it can't be elsewhere
[10:28] <kitche> sure it can just not like how Novell does it since Novell knows know Xen works inside and out
[10:29] <decriptor> true
[10:30] <decriptor> novell has some big resources working on it
[10:30] <decriptor> but
[10:31] <LaserJock> decriptor: so we don't have as much resources
[10:31] <LaserJock> decriptor: that doesn't me we don't care about XEN
[10:31] <decriptor> that's not why I thought that
[10:32] <decriptor> most ubuntu users that I know only talk about KVM
[10:32] <decriptor> and I get almost no response when asking about XEN
[10:32] <LaserJock> maybe KVM is just hotter, I don't know
[10:33] <LaserJock> the fad of the day ;-)
[10:33] <decriptor> I think you have a very good point in and outside of the conversation
[10:34] <decriptor> :-/
[11:02] <PauloZanoni> I added a "script.sh" in the rc2.d directory, its first line contained "#!/bin/bash", but ubuntu was running it as if it were a SH script (not BASH). then, I renamed it to "script" and ubuntu started running it as a BASH script... WHY is ubuntu looking at file name extensions???????
[11:11] <sbalneav> PauloZanoni: It doesn't
[11:13] <PauloZanoni> sbalneav: It happened only when the script was at rc2.d ...
[11:13] <PauloZanoni> there was a link to it there =)
[11:19] <PauloZanoni> sbalneav: just a correction: the link in rc2.d must have ".sh" in its name for the "bug" to be reproduced
[11:20] <sbalneav> It's not a bug.
[11:21] <sbalneav> have a look at /etc/init.d/rc
[11:21] <sbalneav>        # Debian Policy 9.3.1 requires .sh scripts in runlevel S to be sourced
[11:21] <sbalneav>         # However, some important packages currently contain .sh scripts
[11:21] <sbalneav>         # that do "exit" at some point, thus killing this process.  Bad!
[11:21] <sbalneav>         #[ S = "$runlevel" ]  && sh=.
[11:22] <PauloZanoni> sbalneav: I see....
[11:23] <PauloZanoni> sbalneav: isnt the unix philosophy to not look at file names?
[11:24] <sbalneav> Debian Policy 9.3.1 requires .sh scripts in runlevel S to be sourced
[11:24] <PauloZanoni> sbalneav: hmmm.... ok, thanks!
[11:25] <sbalneav> sometimes you may need things sourced, instead of executed separately.
[11:25] <sbalneav> if you do, you put a .sh.
[11:25] <sbalneav> it's a well defined policy for rc scripts.
[12:20] <Kopfgeldjaeger> gn8