  Upon reboot the number remains at 48, but the mouse pointer reverts back to small. Anyone else experience this?
[22:46] <well_laid_lawn> xubuntu90w:  does it happen if you log out then back in ?
[22:47] <well_laid_lawn> hae ou tried saving the session ?
[22:47] <well_laid_lawn> hae you tried saving the session ?
[22:49] <xubuntu94w> okay, sounds good.
[22:50] <xubuntu94w> I have a question: I'm no longer sure how to download packages. how can I fix this? am I just dong something simple wrong?
[22:53] <well_laid_lawn> what happens if ou use the software center ?
[22:55] <xubuntu94w> I dunno. is that where I should go?
[22:55] <well_laid_lawn> try that first - should be in the menu
[22:55] <xubuntu94w> after having my system updated, I'm no longer sure where to go. okay, I'll look for that.
[22:58] <xubuntu94w> looking under "All," I'm able to see "Software & Updates," and "Software Installer."
[22:58] <xubuntu94w> your lawn also sounds amazing.
[22:59] <well_laid_lawn> heh
[23:01] <xubuntu94w> okay, I looked at Software & Updates, but it's not like the package installer I used to use, where I could search for different programs.
[23:02] <xubuntu94w> is there a way to search for certain programs, or is that in another place?
[23:02] <saor> xubuntu94w: I get this with my mouse settings somtimes, manually editing the .xml helped in my case.
[23:03] <xubuntu94w> hmm, okay. I'm totally not a programmer at all, so stuff like that is foreign to me.
[23:04] <xubuntu94w> jeez, Church was in and out. If only real church was like that, I might attend!
[23:04] <xubuntu94w> if I believed in God!
[23:45] <xubuntu94w> did I just alienate everyone, or is this long of a pause normal?
[23:48] <tomreyn> xubuntu94w: it's normal (when it's not obvious that there are open support questions). about your software installations, you can use either use apt in a terminal or synaptic.
[23:48] <tomreyn> or the ubuntu software store, but ... personally i would not.
[23:49] <xubuntu94w> okay. I'm not a programmer. like, how do I download packages and stuff? I still don't know.
[23:49] <xubuntu94w> I used to be able to, but not since I have this newest version.
[23:50] <xubuntu94w> or maybe it's going from Mate to xubuntu? I'm not sure.
[23:54] <xubuntu90w1> hello, in Xubuntu <IP_ADDRESS>, my mouse pointer size wont stay large after reboot, I set the mouse pointer to size 48, and for the session it stays large, but then after reboot, it reverts back to small pointer, although the size selector roller remains at size 48, the mouse pointer is small again. Any one else having this problem or know of a fix?


[00:00] <wgrant> I think +activity is the one Launchpad page that doesn't use your configured timezone
[00:00] <exarkun> Thanks.
[00:00] <wgrant> Bug #412963 is relevant here
[02:30] <Timothy_Gu> I have a PPA, but I have some questions about versioning. Do I have to use 1.0-0ppa1 or 1.0-0~ppa1?
[05:05] <MTecknology> so... I've been having an issue and I think I see the issue now... apparently ppa.launchpad.net has no ipv6 addy? :(
[14:34] <shadeslayer> hi, is there a way to query the launchpad API for the build status based on just the build id?
[14:38] <dobey> shadeslayer: a recipe build, or a package build?
[14:38] <shadeslayer> dobey: package build
[14:39] <dobey> shadeslayer: it seems you can for distribution packages, but i am not sure about PPA packages
[14:39] <dobey> https://launchpad.net/+apidoc/1.0.html#build
[14:40] <dobey> oh, but you need the distribution name and source package name, as well as the id
[14:41] <PN1> Hi, i opened a new ppa and i have a build error about gstreamer-sdk-dev. anyone know how to add it to build-depends?
[14:42] <shadeslayer> yeah
[14:43] <shadeslayer> PN1: check debian/control
[14:43] <shadeslayer> also, #ubuntu-packaging would be the right place
[14:43] <shadeslayer> if no one answers there, #ubuntu-motu :)
[14:43] <PN1> i did and the Build-Depends line look like this: Build-Depends: debhelper (>= 8.0.0), gstreamer-sdk-dev
[14:43] <shadeslayer> and?
[14:44] <PN1> but i get an error: gstreamer-sdk-dev: missing
[14:44] <PN1> gstreamer-sdk-dev: does not exist
[14:44] <dobey> gstreamer-sdk-dev isn't a package
[14:44] <PN1> in the log file at my PPA
[14:44] <dobey> and #ubuntu-packaging is the right channel to ask for packaging help
[14:45] <dobey> PN1: you can't depend on things that don't exist
[14:45] <shadeslayer> ^
[14:45] <dobey> shadeslayer: i'm not sure what source_ids are exactly, but getBuildSummariesForSourceIds() on an archive object *might* do what you want
[14:46] <shadeslayer> dobey: well .. I'm thinking of writing something that notifies me when my builds complete
[14:46] <shadeslayer> and I assumed that the build id would be a unique identifier that I could use to query lp
[14:46] <dobey> shadeslayer: well, how are you getting the build id?
[14:47] <shadeslayer> manually from the user
[14:47] <dobey> oh
[14:48] <shadeslayer> and the idea is specifically for PPA's because I have to keep refreshing build pages to check if the build completed or not
[14:49] <shadeslayer> didn't even think of supporting archive builds atm
[14:49] <shadeslayer> I guess a reasonable way to do it would be to monitor the entire PPA
[14:55] <shadeslayer> hm
[14:55] <dobey> shadeslayer: well i think a PPA is an "archive" object in the lp api
[14:55] <shadeslayer> right
[14:55] <shadeslayer> and I can check build pages uniquely like this : https://launchpad.net/builders/+build/3910669
[14:55] <dobey> you just need the source id
[14:55] <dobey> which /may/ be the same as the build id you're talking about
[15:07] <shadeslayer> dobey: http://paste.kde.org/572228/raw/ does it nicely
[15:09] <dobey> shadeslayer: right; that'll give you everything currently building; if that's more what you wanted, than specific build ids, we could probably work out a nice little notifier script and shove it in lp:lptools if you'd like
[15:09] <shadeslayer> kinda
[15:09] <shadeslayer> this will have to do at the moment
[15:10] <shadeslayer> the developer specifies the PPA where he uploaded things, and I poll for Needs Building/Currently Building
[15:11] <shadeslayer> then you show a notification as soon as the build fails
[15:11] <shadeslayer> or succeeds for that matter
[17:56] <chrisccoulson> hmm, i'm getting this when trying to upload to a PPA:
[17:56] <chrisccoulson> Uploading firefox_17.0~b2+build1.orig.tar.bz2: 550 Requested action not taken: internal server error
[18:00] <chrisccoulson> ok, i can't download anything from ppa.launchpad.net either
[18:01] <chrisccoulson> well, not at any reasonable speed....
[18:12] <dobey> chrisccoulson: i have the same problem uploading to a ppa with a much smaller package even :-/
[18:13] <chrisccoulson> dobey, oh, i'm glad it's not just me then :)
[18:44] <shadeslayer> chrisccoulson: likewise here as wel
[18:44] <shadeslayer> trying to upload a 2 MB package
[18:44] <shadeslayer> uploading was *really* slow
[18:44] <shadeslayer> and then craps out :P
[19:01] <czajkowski> chrisccoulson: dobey shadeslayer asing elsehwere to see
[19:01] <shadeslayer> thx
[19:01] <czajkowski> np
[19:05] <czajkowski> chrisccoulson: dobey shadeslayer there was a little bigh higher than average load, but it's all normal now
[19:06] <shadeslayer> cool :)
[19:06]  * shadeslayer tries again
[19:06] <dobey> ah
[19:07] <shadeslayer> well ... upload speed is still crap, but let's see
[19:08] <LordOfTime> upload speed could be your end, just saying.
[19:08] <shadeslayer> right
[19:09]  * shadeslayer tries via VPS
[19:10] <shadeslayer>   Uploading kdevplatform_1.4.0.orig.tar.bz2: 550 Requested action not taken: internal server error
[19:10] <shadeslayer> N
[19:11] <shadeslayer> so still not fixed for me ( uploading via VPS )
[19:11] <LordOfTime> o.O
[19:11] <LordOfTime> ppa upload processor issue?
[19:11] <chrisccoulson> yeah, it's being investigated at the moment
[19:11]  * shadeslayer will wait
[19:28] <TheLordOfTime> any idea why an OpenID auth system would 403 on launchpad, even though they offer that as an auth option on a given site?
[20:37] <joey> sinzui: how often does the flag-expired-memberships script run? I thought it ran nightly with a 14 notice window. I ask because I think I should be getting expiry notices.
[20:38] <joey> and I'm not
[20:38] <sinzui> nightly is correct
[20:38] <joey> I might need to give it another day. I just realized today is 14 days
[20:39] <joey> so maybe I'll get something tonight
[21:28] <jelmer> hmm, my uploads to precise-proposed - despite an email confirming the upload - seem to be disappearing
[21:30] <zooko> Folks: this page doesn't have what I want to do which is "register my bug tracker or update the settings of my bug tracker in launchpad's worldview". https://help.launchpad.net/Bugs
[21:37] <zooko> Okay, I posted that as a question: https://answers.launchpad.net/launchpad/+question/211504
[21:53] <maxb> zooko: This may be what you want: https://bugs.launchpad.net/bugs/bugtrackers/
[22:20] <terceiro> just got this in an email:
[22:20] <terceiro> Your message to <launchpad> was automatically rejected:
[22:20] <terceiro> Not enough disk space
[22:20] <terceiro> where should I report this?
[22:22] <wgrant> terceiro: When was that?
[22:22] <shadeslayer> dobey: wrote a script to keep polling the buildstate in a thread, but it's almost as if the build object doesn't get updated once a build is done
[22:23] <wgrant> jelmer: Is that still a problem?
[22:23] <MTecknology> ppa.launchpad.net has no ipv6 address... how am I supposed to add ppa repos to ipv6-only servers?
[22:24] <wgrant> MTecknology: You're not.
[22:24] <wgrant> Not yet.
[22:24] <jelmer> wgrant: is it a known issue?
[22:24] <wgrant> jelmer: No
[22:24] <MTecknology> :(
[22:25] <terceiro> wgrant: right now; original message sent at Wed, 17 Oct 2012 21:02:30, returned message at Wed, 17 Oct 2012 21:02:51 (all times UTC)
[22:25] <MTecknology> so I have to download the .debs to one system then upload from that system, and just keep watch of updates?
[22:25] <terceiro> wgrant: want message-ids?
[22:25] <terceiro> or headers?
[22:25] <wgrant> MTecknology: Pretty much
[22:26] <wgrant> MTecknology: Or proxy through an IPv4-capable host
[22:26] <MTecknology> I don't have any system that I could use for that..
[22:26] <MTecknology> hrm..... maybe one.....
[22:27] <wgrant> terceiro: There was an issue a couple of hours ago. Is it still happening?
[22:27] <wgrant> jelmer: Where exactly is it not showing up?
[22:28] <terceiro> wgrant: it was just this one message AFAICT
[22:28] <terceiro> can I just bounce it back?
[22:28] <wgrant> terceiro: That's what I'd try
[22:28] <wgrant> The issue wasn't around for long, and is resolved
[22:28] <wgrant> jelmer: I see a samba upload from you in Unapproved.
[22:28] <terceiro> wgrant: all right, thanks
[22:28] <wgrant> samba4, sorry
[22:28] <jelmer> wgrant: the build email claims that it is waiting for approval and provides a link https://launchpad.net/ubuntu/precise/+source/samba4/4.0.0~alpha18.dfsg1-4ubuntu3
[22:28] <jelmer> but that link gives me a 404 page
[22:29] <wgrant> jelmer: Right, it's waiting for approval
[22:29] <wgrant> An archive admins must approve all post-release uploads
[22:29] <jelmer> ah, now I see it in the unapproved queue too
[22:29] <wgrant> https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
[22:29] <wgrant> Yeah
[22:30] <jelmer> it's just very confusing that it does provide that link in the email despite not yet being available.
[22:30] <jelmer> wgrant: thanks
[22:32]  * jelmer looks for a relevant bugreport
[22:33] <jelmer> bug 115078 seems related


[13:26] <thorwil> newz2000: hi! could you change the "--" a signature added via @SIGæ in the wiki into an – ?
[13:26] <thorwil> damn, i must be a quibbler :)
[15:49] <savvas> does ubuntu-website handle editing configuration files of the wiki?
[15:50] <newz2000> savvas: no, you'll need to file an RT about that, do you know how to do that?
[15:51] <savvas> I'll have to forward bug #301830 and bug #300997 then :)
[15:51] <ubot3> Malone bug 301830 in ubuntu-website "PageList Style Formatting" [Undecided,Confirmed] https://launchpad.net/bugs/301830
[15:51] <ubot3> Malone bug 300997 in ubuntu-website "monthcalendar on ubuntu wikis - unattractive brown/red colours" [Undecided,Confirmed] https://launchpad.net/bugs/300997
[15:51] <savvas> newz2000: rt at ubuntu.com right?
[15:51] <newz2000> correct
[15:51] <savvas> ok on my way! thanks for the prompt reply!
[15:58] <savvas> newz2000: can you please unsubscribe ubuntu-website team from those two bugs?
[15:58] <newz2000> yes
[15:58] <savvas> thanks, I've set them as invalid :)
[16:00] <savvas> ok sent to rt
[16:00] <savvas> cheers!


[10:50] <amitk> ogra: do you guys plan to roll Pegatron images too? considering the slight changes required to redboot...
[10:51] <ogra> if i can get the redboot patches in plain form i will include redboot binaries for pegatron and it would be nice to have kernel support too, we wont build specific images though, but we would like to enable oters to do so
[10:51] <lool> I would like to split the images so that we ship a small device dependent image and load the squashfs from a separate image
[10:52] <lool> We need to revisit the image format; SD images aren't particularly useful for real lange devices
[10:52] <ogra> yep
[10:52] <ogra> though thats karmic+1, right ?
[10:52] <lool> That's as soon as possible but not a karmic goal in itself  :)
[10:52] <ogra> or do you plan it for this cycle ?
[10:52] <ogra> good
[10:53]  * ogra would like to have images at all before thinking about a redesign :)
[10:54] <lool> We do now
[10:55] <lool> Just with broken casper (Fix committed) and kernel
[10:55] <ogra> right
[10:55] <ogra> once i see it booting to gdm and can use mouse kbd and network i'm happy
[10:56] <ogra> lool, in any case i dont want to have a cycle again where we dont start building images with A1
[10:57] <lool> I wish, but I doubt it will be much faster to rebase on top of .33 or whatever is used in 10.04
[10:57] <ogra> even if that means to carry the kernel of the last release for a while
[10:57] <lool> Perhaps for dove
[10:57] <ogra> well, with the sperate kernel sourcepackages it should be a bit easier
[10:57] <amitk> so you worked around the squashfs problem or was it fixed?
[10:57] <ogra> no
[10:57] <ogra> neither
[10:58] <ogra> its broken atm
[10:58] <amitk> how can I reproduce it? Since I don't typically install the entire system to test kernels...
[10:59] <ogra> hmm, well, you would need to pul the live image
[10:59] <ogra> then change the cmdline and add LIVEMEDIA=/dev/mmcblk0p2
[10:59] <amitk> link?
[11:00] <ogra> http://cdimage.ubuntu.com/ports/daily-live/20090812.4/karmic-desktop-armel+imx51.img
[11:00] <amitk> straight dd to SD?
[11:00] <ogra> yup
[12:10] <ogra> argh
[12:10]  * ogra curses git
[12:11] <ogra> so my day is messed already having to use that crap
[12:14] <ogra> so no matter what i do to get the mvl-dove branch it simply trashes what i have already
[12:14] <amitk> what are you trying to do?
[12:15] <ogra> lool wanted me to do a testbuild and i simply clone the ubuntu-karmic branch, then try to checkout the mvl-dove head (which apparently isnt included)
[12:16] <amitk> ogra: what does 'git branch -r' say
[12:16] <ogra> so i started lookinf for docs that confuse even more, isnt there a simple clone command i can use to get directly what i want ?
[12:16] <ogra> ah, it has origin/mvl-dove
[12:16] <ogra> but note i messed it up already editing .git/config
[12:17] <ogra> and running git pull afterwards
[12:17] <amitk> so just do 'git checkout origin/mvl-dove -b mvl-dove'
[12:17] <ogra> which results in a broken merge
[12:17] <amitk> NEVER EVER use git pull. Don't you bzr heads ever learn :-p
[12:18] <ogra> well, if git would be usable in any small amount we wouldnt need bzr :P
[12:18] <amitk> Here are the commands to fix your setup:
[12:18]  * ogra starts over with a clean clone
[12:18] <ogra> oh, ok
[12:18]  * ogra listens
[12:18] <amitk> git checkout master
[12:18] <amitk> git reset --hard origin/master
[12:18]  * amitk waits
[12:19] <ogra> ok
[12:19] <ogra> Switched to a new branch 'mvl-dove'
[12:19] <ogra> ha !
[12:19] <amitk> git fetch
[12:19] <ogra> oh
[12:19] <ogra> ok
[12:20] <amitk> what does 'git branch' say?
[12:20] <ogra> ogra@osiris:/var/build/kernel/git/ubuntu-karmic$ git branch
[12:20] <ogra>   master
[12:20] <ogra> * mvl-dove
[12:21] <amitk> git reset --hard origin/mvl-dove
[12:21] <amitk> just to be sure you are on tip of mvl-dove
[12:21] <ogra> HEAD is now at 32e3175 UBUNTU: [Config] Bypass udeb generation issues.
[12:21] <ogra> looks good
[12:21] <amitk> now you can carry on building
[12:22] <ogra> yep i guessed so
[12:25] <ogra> amitk, thanks a lot, git is like speaking latin to me
[12:26] <amitk> actually it _is_ due to the archival nature of internet. Everything published on internet should have a expiry date. All the bad docs would disappear then.
[12:47] <amitk> hmm... why does the karmic fsl image switch the console after initramf
[12:47] <amitk> s
[12:47] <ogra> ??
[12:47] <ogra> can you elaborate ?
[12:48] <amitk> http://pastebin.ubuntu.com/252445/ after this I get nothing on my serial console
[12:48] <amitk> everything is redirected to the DVI output
[12:49] <amitk> where I see initramfs errors
[12:50] <ogra> oh, right, because its a live image
[12:50] <ogra> edit the cmdline
[12:50] <ogra> drop console=tty0
[12:51] <ogra> though given that upstart has no default setup for serial ttyS i doubt you will get a lot more (beyond the errors)
[12:51] <ogra> lool, the mvl-dove kernel doesnt boot
[12:53] <ogra> lool, whoops, i take that back, wrong mkimage parameters
[13:14] <amitk> lool: you comment on the squashfs bug: babbage image doesn't find its livefs by default (due to a driver renaming its /sys data between 2.6.28 and .31)
[13:15] <amitk> that should be the squashfs driver?
[13:15] <ogra> no, thats the casper bug he was referring to earlier
[13:15] <amitk> so now it does find its livefs by default?
[13:16] <ogra> we currently look for platform-mmc devices but that device was renamed
[13:16] <ogra> the casper fix adds the new name to it i belive (i didnt check it)
[13:16] <ogra> you can override the broken casper detection by setting LIVEMEDIA=/dev/mmcblk0p2 on the cmdline
[13:17] <ogra> the detection isnt realted to the squashfs oops
[13:17] <ogra> its two separate issues
[13:17] <amitk> its almost impossible for me to debug this bug w/o a separate DVI display. Can't keep switching between the board and my devbox. Do you have any other trick?
[13:18] <ogra> sadly no
[13:19] <ogra> dropping console=tty0 didnt help ?
[13:23] <amitk> it helps. But I don't have enought knowledge of initramfs
[13:23] <amitk> where does the stdin: error 0 come from?
[13:26] <amitk> aah, nevermind. passing LIVEMEDIA makes it go away
[13:38] <lool> amitk: There is a casper fix which isn't uploaded which is why you need the LIVEMEDIA arg
[13:38] <lool> Main console is on DVI by default but you can easily change that on the kernel cmdline
[13:38] <ogra> lool, dove looks very good so far
[13:39] <lool> ogra: What did you test?
[13:39] <ogra> its nearly finished doing a kernel compile
[13:39] <ogra> never got that far before, should be done within the next 15min
[13:39] <amitk> ogra: it better be. They delivered a 2.6.31 patchset...
[13:40] <ogra> well, we had weird segfaults and ICEs with all former versions
[13:40] <ogra> nothing like that anymore it seems
[13:40] <ogra> and since i built a .deb from our git tree i'll try initramfs booting next
[13:41] <ogra> it still doesnt see the 512M though
[13:44] <ogra> ogra@dove:~$ sudo hdparm -t /dev/sda1
[13:44] <ogra> /dev/sda1:
[13:44] <ogra>  Timing buffered disk reads:  170 MB in  3.15 seconds =  53.99 MB/sec
[13:44]  * ogra really loves that
[13:47] <amitk> ogra: did you say there was a dove board to be delivered to me too?
[13:47] <ogra> we had a spare one but you guys were all gone already
[13:47] <ogra> not sure where that went now
[13:48] <ogra> lool, do you remember ? ^^^
[13:52] <ogra> mage arch/arm/boot/uImage is ready
[13:52] <ogra> HA !
[13:53] <ogra> lool, i'd consider the stability issues solved
[14:23] <lool> ogra: Do you have CONFIG_HIGHMEM on your kernel?
[14:23] <lool> ogra: How much memory do you see in free?
[14:23] <lool> or /proc/meminfo rather
[14:24] <ogra> ogra@dove:~/temp$ cat /proc/meminfo
[14:24] <ogra> MemTotal:         286664 kB
[14:24] <ogra> # CONFIG_HIGHMEM is not set
[14:24] <ogra> aha
[14:24] <lool> Hmm
[14:24]  * ogra tells rtg
[14:25] <ogra> lets get it set for one testbuild
[14:25] <lool> I don't understand where these 256 MB are
[14:26] <ogra> do you need anything more ? else i'll try a reboot with initramfs
[14:27] <lool> No I don't thanks
[14:47] <ogra> hmm
[14:47] <ogra> Wrong Ramdisk Image Format
[14:47] <ogra> i wonder why
[14:47] <ogra> i can load it just fine but it panics
[14:50] <ogra> cat /ogra@dove:~$ cat /proc/meminfo
[14:50] <ogra> MemTotal:         514248 kB
[14:50] <ogra> hmm, works if i set mem=512M
[14:50]  * ogra tries to complie something to see if it stays stable
[15:06] <lool> ogra: Are you using the latest U-Boot?
[15:07] <lool> You want the latest one
[15:07] <ogra> ah, no
[15:07] <ogra> do we know how to safely flash it ?
[15:07] <ogra> i dont want to trash my board now that it actually runs stable
[15:09] <lool> Not sure
[15:09]  * ogra tries another kernel build with mem=512M
[15:10] <ogra> lets see if it keeps stability
[16:11] <tlee> Anyone know a good ubuntu-arm-vfp rootfs when I can download.
[16:27] <lool> vfp nope


 How to install kubuntu
[10:02] <carmine> hi
[13:32] <BluesKaj> Hi all
[15:20] <user|37> how can I get audio?
[15:24] <user|37> my audio is not working - please help?
 Hi what’s better for flashing iso? Rufus or Etcher?
[21:21] <tomreyn> etcher works for me, is simple to use, cross platform, does the right things out of the box.


[08:04] <tjaalton> bryce: I've filed a bug to remove fonttosfnt from the archive, bug 235411. you could confirm that if you agree ;)
[08:06] <bryce> tjaalton: okies
[08:08] <tjaalton> hmm, a couple of pending sync requests.. guess they'll be processed soon
[08:10] <tjaalton> so, there'll be libdrm 2.3.1 without any memory-manager goodness
[08:29] <tseliot> tjaalton: I'm uploading the source code of my packages to my website. NOTE: I haven't touched the control files (as regards dependencies) and haven't carefully checked the diversions, however I would like you to review what I have done so far.
[08:32] <tjaalton> tseliot: ok, cool
[08:34] <tseliot> tjaalton: I haven't removed the dependency on linux-restricted-modules-common yet since we are not sure about its removal and I had to add a "-modaliases" package so that we don't screw up jockey
[09:21] <tjaalton> wow, Wolfram answered to bug 197163
[09:22] <tjaalton> so we are buggy at least in some respect, because there are no usable Courier and Times fonts (msttcorefonts not helping here)
[09:29] <tjaalton> hm, though it should help
[09:33] <tjaalton> fedora seems to have urw-fonts which is a free bundle of tt-fonts
[09:36] <bryce> tjaalton: true
[09:37] <tjaalton> I'll see what it takes to package that
[09:45] <tseliot> tjaalton: here is a txt file which contains all the links to the source code: http://www.albertomilone.com/ubuntu/newlrm/lrm-links.txt
[09:45] <tjaalton> apparently gsfonts should have the fonts..
[09:45] <tjaalton> tseliot: thanks
[09:46] <tjaalton> I'll just grab the directory
[09:46] <tseliot> in the meantime I'll work on the xorg parser for bryce
[09:47] <tjaalton> uh, forbidden
[09:48] <tseliot> yes, I know
[09:49] <tseliot> you should wget the links in that txt file
[09:49] <tjaalton> works
[09:50] <tjaalton> ok, the version number is wrong :) -1 is reserved for debian, this should be -0ubuntu1
[09:51] <tseliot> yes, I (temporarily) used exactly the same version as the debian package
[09:52] <tjaalton> ok, that just makes no sense :)
[09:53] <unggnu> hi all
[09:53] <tjaalton> hi unggnu
[09:53] <unggnu> According to mail [ubuntu-x] Xorg Triaging Projects it is not possible for non developers to set Wont' fix
[09:53] <unggnu> hi tjaalton
[09:54] <unggnu> Only solution is to set to invalid I guess or get the permission to use Wontfix.
[09:55] <tjaalton> or join ubuntu-bugcontrol
[09:56] <unggnu> Do you have a link?
[09:56] <tjaalton> https://edge.launchpad.net/~ubuntu-bugcontrol
[09:57] <unggnu> thx
[09:59] <unggnu> Btw. isn't it possible with a script to mark all displayconfig-gtk bug reports which have only one package association with Wontfix and add the description?
[10:01] <tjaalton> should be, but I'm not familiar with the mail-interface
[10:02] <unggnu> Ok
[10:06] <unggnu> Is something planned for people with hardware which send wrong data or something like that? Some can't even fixed with a quirk afaik. It is possible to change xorg.conf manually but it isn't so easy I guess for most people.
[10:06] <unggnu> e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/191000
[10:17] <unggnu> I guess a tool with a "problem monitor" db would be great or the ability to import windows monitor drivers and change the xorg.conf settings with this information. Afaik displayconfig-gtk had the second ability. Maybe only the monitor part can be extracted.
[10:55] <unggnu> Another problem are CRT displays afaik. It is possible to change the user resolution with the screen resolution tool but not the login one and afaik X uses the highes possible one which doesn't look so well on CRTs.
[10:57] <unggnu> Are there any plans for this problems?
[11:05] <unggnu> bbl
[11:06] <tjaalton> CRT's are dying anyway ;)
[11:07] <jcristau> unggnu: X uses the mode that your monitor reports as preferred
[11:07] <jcristau> unggnu: if that doesn't work then it can be quirked
[11:08] <tjaalton> yeah the first problem seemed like it should be able to be quirked, since it tries to use a wrong mode
[11:21] <tjaalton> maybe the inted engineer meant that it's not possible to quirk the driver
[11:21] <tjaalton> *intel
[11:25] <jcristau> the initial mode selection code has changed a lot recently though
[11:25] <jcristau> so maybe the server from git does a better job
[11:25] <jcristau> in any case this looks like a bug in the server, not xf86-video-intel?
[11:27] <tjaalton> yeah
[11:59] <unggnu> re
[12:00] <unggnu> jcristau: so a CRT sends the data that he supports resolutions up to 1600x1200 but prefers 1280x1024?
[12:00] <unggnu> sorry, it supports :)
[12:00] <jcristau> yes
[12:01] <unggnu> But why are so many people with CRT complaining about it?
[12:04] <unggnu> Anyway, if xserver uses this preferred mode it is Ok I guess. I can't test it since I haven't any CRT anymore. Yes, they are dying :)
[12:07] <unggnu> I guess in future the biggest part of the driver are quirks ;)
[12:07] <jcristau> no
[13:11] <unggnu> bbl
[16:32] <bryce> tjaalton: do you know of any reasons we should put a newer fglrx into 8.04.1 (deadline's coming up)
[16:41] <tjaalton> tjaalton: I'll read the relnotes to see if there's anything
[16:42] <tjaalton> I didn't realize there was a deadline :/
[16:43] <bryce> yeah sunday is the cutoff for getting things into 8.04.1
[16:43] <tseliot> tjaalton: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/catalyst_85_linux.html
[16:43] <tseliot> BTW they broke the API
[16:46] <bryce> tseliot: erf
[16:48] <tjaalton> tseliot: meaning?
[16:50] <tjaalton> eh, the list of known issues keeps getting longer..
[16:50] <tseliot> tjaalton: it means that you will have a lot of fun packaging it
[16:51] <tseliot> furthermore the ati installer doesn't include Mario's latest scripts
[16:51] <tseliot> therefore I suggest you to get such scripts from git and see what's changed
[16:52] <tseliot> I'm planning to make this driver available through EnvyNG too (sooner or later)
[16:52] <tseliot> bryce: have a look at my email when you have the time
[16:53] <bryce> tseliot: ok just replied
[16:53] <tseliot> bryce: thanks
[17:25] <bryce> heya unggnu
[17:25] <unggnu> hi bryce
[17:25] <bryce> tseliot, tjaalton: so sounds like the new fglrx is too sketchy to think about including for 8.04.1?
[17:26] <unggnu> Can't someone ask an Launchpad expert or maintainer if this is possible to close all displayconfig-gtk bugs since they don't seem to need user interaction.
[17:26] <unggnu> I thought updating fglrx or nvidia isn't possible or at least feasible? At least I have read it somewhere.
[17:26] <tseliot> bryce: yes, I guess so
[17:27] <bryce> unggnu: normally yes, but I got a dispensation for it for 8.04.1 -- but it makes sense to do it only if we know it will fix issues and we're confident it won't bring regressions
[17:28] <unggnu> ok
[17:32] <bryce> unggnu: I was going to just close the dcg bugs manually, so I could check that they're actually dcg bugs, and give additional answers where appropriate
[17:34] <unggnu> Ok, that's a point. I could be minimize through closing simply the displayconfig-gtk only bugs but the risk is still there.
[17:36] <unggnu> So kde-guidance should be closed too?
[17:36] <bryce> I believe so, but check with scottk
[17:39] <tjaalton> bryce: yep
[17:44] <johanbr> bryce: About the Radeon lockup bug (bug #234811), "xrandr -s 1440x900" works (in contrast to doing it with the GUI, which causes a hard lockup).
[17:45] <bryce> johanbr: *nod* that's too bad, since if it could be reproduced with xrandr we could forward the report upstream
[17:45] <bryce> johanbr: as it is, it may be some issue with gnome-display-properties' randrwrap code
[17:45] <unggnu> What happens with Bullet-Proof-X in Intrepid?
[17:46] <bryce> unggnu: timo and I discussed it and are thinking we'll drop it
[17:46] <johanbr> Even so, there's an X server or driver bug in there somewhere, right? I'd think the GUI shouldn't be able to bring everything down.
[17:46] <bryce> right
[17:47] <bryce> it's definitely a legit X bug, just not clear yet how to troubleshoot it
[17:47] <unggnu> I liked the idea very much but was never lucky with displayconfig-gtk.
[17:47] <johanbr> bryce: I haven't yet tried asking him to rebuild the Gutsy version of the driver. I'll do that.
[17:48] <unggnu> Theoretically it isn't needed if the Vesa fallback of Xorg works fine.
[17:48] <bryce> johanbr: basically what needs to happen is to dig through the code and identify which Xrandr protocol calls are generating the problem, make a test case that reproduces the issue, and forward that upstream
[17:48] <bryce> johanbr: but I think requesting a user code up a test case in C for us is probably asking much ;-)
[17:49] <bryce> possibly there is a way we could gather more detailed logs or something from g-d-p, but I don't recall offhand
[17:50] <johanbr> I guess running g-d-p under gdb and putting in some carefully chosen breakpoints would do the trick.
[17:55] <bryce> johanbr: possibly
[17:56] <bryce> johanbr: although I suspect it probably just happens during the protocol call
[17:56] <bryce> might be able to dig out some state info and such, although it would be difficult to talk a user through all that in gdb
[17:57] <bryce> but perhaps breaking on that call and getting a full backtrace would be doable
[17:57] <bryce> it would be good to have a documented procedure on this, as there's been a few other such reports and I daresay we may be getting more in the future
[18:00] <johanbr> He's new to linux, but interested in helping to resolve the bug and not afraid of reading man pages and such. I'll see what I can do.
[18:04] <unggnu> I guess it is Ok to drop bulletproof. X still is very picky about things in xorg.conf but it could be easily repaired through Recovery Mode. Maybe it would be great to start X without an xorg.conf instead of Bulletproof if X couldn't start.
[18:06] <unggnu> Maybe with a question after login for the admin users if the xorg.conf should be recreated like xfix does.
[18:08] <unggnu> Ok, could be a loop but a simple check could prevent it. I don't know. People like their GUIs :)
[19:13] <bdmurray> tjaalton: is bug 113679 specific to nvidia hardware?
[19:19] <bryce> unggnu: yeah... ideally I'd like to replace displayconfig-gtk with something, but there's not really anything viable at the moment
[19:21] <unggnu> bryce: Xfix would do the job I guess if there is not a general Xorg/vesa problem.
[19:22] <bryce> unggnu: yeah that's what I'm thinking too
[19:23] <bryce> another option would be to strip down displayconfig to remove the multi-screen stuff and other bits that could cause confusion
[19:23] <bryce> we really don't have a good solution for the corner case of edid failures or where edid is not being provided by the monitor
[19:24] <bryce> i.e., http://bugs.launchpad.net/ubuntu/+bug/edidfail
[19:24] <unggnu> Would be great too for wrong edid data but afaik the conventions have changed. Modelines are ignored at lest for the intel driver. Mainly it would be a rewrite I guess.
[19:24]  * bryce nods
[19:25] <bryce> wow I didn't know they're ignoring modelines now
[19:25] <unggnu> Afaik of course :)
[19:27] <unggnu> something with PreferredMode
[19:27] <unggnu> http://www.intellinuxgraphics.org/dualhead.html
[19:29] <unggnu> also described here in the latest comment https://bugs.freedesktop.org/show_bug.cgi?id=14726
[19:30] <unggnu> bbl
[19:33] <tjaalton> bdmurray: shouldn't be AFAIK
[19:34] <bdmurray> tjaalton: Okay, I saw a couple of references to nvidia in it.  Is there a test case at all?
[19:37] <tjaalton> bdmurray: I don't think there is an easy way to reproduce it.. we have a couple of hundred desktops (all nvidia) and don't remember anyone reporting issues with OO.o :)
[19:37] <tjaalton> even with dapper
[19:37] <bdmurray> hrm, that'll be interesting then
[19:40] <tjaalton> apparently the fix works, since the google guys haven't seen the problem since upgrading to the version on my ppa
[19:51] <bryce> unggnu: hmm I read that as meaning that the order of the resolutions is ignored, but the resolutions themselves are accepted, and I read that as modelines are still accepted
[19:52] <bryce> unggnu: the issue seemed to be that the user added a mode, but couldn't get it to be taken as the default resolution in the new x server by simply listing it first in the list - he had to add it as the preferred mode
[19:52] <bryce> (I could be wrong though, but that was my interpretation)
[20:04] <bryce> good gem vs. ttm article:  http://lwn.net/Articles/283793/
[20:05] <bryce> copy of it here:  http://pastebin.com/m1a80b77b
[20:06] <tjaalton> wow, the topic suggested by Mirv :)
[20:22] <unggnu> bryce: I never got Modelines working with the -intel driver but I am not sure.
[20:24] <unggnu> Maybe it only accepts the modeline if preferredmode is used.
[20:25] <unggnu> It seems so http://lists.freedesktop.org/archives/xorg/2008-February/032791.html but I don't understand why they use a new option for an old feature?
[20:27] <tjaalton> it's randr-1.2, same thing with radeon AFAIK
[20:29] <tseliot> unggnu: something like this would work:
[20:29] <tseliot> Modeline "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync
[20:29] <tseliot> Option "PreferredMode" "1280x1024_75.00"
[20:29] <unggnu> I think so. So the tool have to add a Modeline and PreferredMode.
[20:32] <bryce> unggnu: probably the xrandr changes altered how things worked internally
[20:32] <unggnu> Yeah, Xorg devs are very fast forward :)
[20:33] <tseliot> bryce: thinking of the special case which you suggested in the email, we can test such case with my program, which I will keep separate from the parser, and decide which approach we should adopt.
[20:33] <bryce> I think there didn't used to be the idea of a PreferredMode so adding that feature broke old behavior
[20:34] <bryce> tseliot: good to hear.  it could help prevent xorg.conf's from getting chugged up with extraneous cruft (which tends to exacerbate troubleshooting issues)
[20:35] <tseliot> bryce: I would like to make both parts maintainable and easy to use so that at least the parser can be shared between different applications. We'll see how it goes...
[20:36] <tseliot> tjaalton: quoting from Phoronix "NVIDIA this morning has released the 173.14.05 driver,  which marks the return to their old naming convention"
[20:37] <bryce> tseliot: heh
[20:37] <tseliot> tjaalton: this release supports kernel 2.6.25 therefore I will have to update the driver and drop the patch for 2.6.25 for driver 169.12
[20:42] <tjaalton> tseliot: cool, it only took them a couple of months..
[20:49] <unggnu> Btw. I have asked this some time ago. Is there any doc how to compile svn Intel driver for normal users without messing up their system?
[20:50] <bryce> there's a few such documents but from my experience users just whine when asked to build from git
[20:50] <bryce> (not that I blame them, I probably would too)
[20:50] <unggnu> But upstream often asks for it.
[20:51] <bryce> right
[20:51] <unggnu> This time the debian sid driver works but it is not often the case afaik.
[20:52] <unggnu> e.g. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/207881
[20:52] <unggnu> this one wanted a patched driver
[20:53] <unggnu> I have tried it but there is one hunk.
[20:57] <unggnu> +failed
[20:58] <bryce> often with patches from upstream I have to recode them a little to make them patch cleanly against the driver we carry
[21:00] <bryce> unggnu: tell you what, I'll take care of 207881
[21:01] <unggnu> thx :)
[21:02] <bryce> unggnu: btw, fyi we have the 8.04.1 cut off date coming up sunday, so what I'm working on now is looking for patches that are complete, verified, and ready for backporting to hardy
[21:02] <bryce> unggnu: so if you could search around for good looking patches that look like they could be put to hardy, please assign them to me
[21:04] <unggnu> Ok, what is the best way? Searching for bug reports with an upstream report and fix released?
[21:04] <unggnu> Or just patches which are already in Intrepid?
[21:05] <bryce> sure both
[21:05] <unggnu> ok
[21:05] <bryce> actually there are probably going to be exceptionally few in the latter category
[21:05] <bryce> so focus on the first
[21:08] <tjaalton> bryce: what was the firefox addon that allows you to open files in firefox instead of it proposing to save it first?
[21:12] <bryce> my notes say "Open In Browser"
[21:15] <bryce> howdy tormod
[21:16] <tormod> heya bryce
[21:16] <bryce> wow, don't think I've seen this many people on #ubuntu-x.  :-)
[21:17] <tjaalton> bryce: hm, either I'm blind or can't find it
[21:18] <bryce> maybe this?  http://www.spasche.net/mozilla/
[21:18] <bryce> looks like it's only for ff2
[21:18] <bryce> (I finally gave up on ff3 yesterday and reverted back to 2)
[21:19] <tjaalton> damn :)
[21:19] <tormod> bryce, due to the disk activity?
[21:19] <bryce> tormod: yeah the periodic freeze-ups that are reportedly due to sql-lite size limits
[21:20] <bryce> tormod: plus a scattering of crash issues (less common now than they used to be though)
[21:20] <tormod> they need a full RDBS in there I guess
[21:20] <unggnu> bryce: What should I do if there is already an assignee?
[21:21] <bryce> tjaalton: hrm, didn't install onto ff2 for me
[21:21] <bryce> unggnu: if it's already assigned to me, then I've already looked at it and it may already be in my queue
[21:21] <unggnu> bryce: no, not you :)
[21:21] <bryce> if it's assigned to the ubuntu-x swat team, you can consider those unassigned
[21:21] <unggnu> bryce: bryce: this one looks good https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/211759
[21:22] <bryce> assigned to anyone else, just mention the bug id to me here and I'll review.
[21:22] <unggnu> cannonical-xorg
[21:22] <tormod> when is launchpad getting per-package bug filing instructions, like attach your Xorg.log...
[21:22] <bryce> ok, treat canonical-xorg to be unassigned as well; that's just a generic team assignment
[21:22] <unggnu> ok
[21:23] <bryce> I'm the only person in canonical-xorg anyway, so all those can just be re-assigned to me.  I don't know who added that team or why, but I don't use it
[21:23] <bryce> tormod: in fact I mentioned exactly that to kiko last week at UDS during one of the "improving launchpad to improve bug reporting" sessions
[21:24] <bryce> tormod: I didn't get a solid commitment to implement such a thing, but favorable noises were made, so we'll see
[21:24] <tormod> bryce: excellent. but it's not like a new idea... it has been requested before I think. hope it helps this time.
[21:25] <tormod> has it been decided that intrepid gets xserver 1.5 and mesa 7.1?
[21:25] <bryce> tormod: this was in particular related with how to improve being able to get bugs upstreamed, which kiko is very passionate about.  I said that if launchpad could be set to require attaching Xorg.0.log to every package managed by the xorg team, it'd probably double our triaging effectiveness
[21:25] <bryce> tormod: yes
[21:26] <tormod> yay for that
[21:27] <tormod> can someone look at my workaround patch for bug 87661, before I ask upstream?
[21:29] <bryce> tormod: looks roughly sane to me (although I didn't read the whole bug report)
[21:30] <tormod> bryce: I don't know so well how 64-bit processors work with different code and kernels etc
[21:51] <unggnu> bryce: I am not sure with this one. It only seems to be a dependency issue so easy fixable but I don't know ... https://bugs.edge.launchpad.net/ubuntu/+source/mesa/+bug/44115
[21:53] <tjaalton> would mean installing libglide3 on every machine
[21:53] <tjaalton> not something to be done on a stable release
[21:53] <tjaalton> or ever
[21:53] <bryce> tjaalton: can it be closed as wontfix then
[21:53] <bryce> ?
[21:54] <tjaalton> imho yes
[21:54] <unggnu> Or put it to suggest like in Debian
[21:54] <tjaalton> it is?
[21:55] <tjaalton> yes
[21:56] <jibel> hi
[21:56] <tjaalton> so it's the same in ubuntu too -> closing the bug
[21:56] <unggnu> hi jibel
[21:57] <jibel> bryce: bug 229043 is fixed in v2.3 of the intel driver. Do you known if it will be fixed in 8.04.1 or earlier ?
[22:19] <bryce> jibel: I'll take a look
[22:27] <jibel> bryce: Thanks. I'll keep informed the reporter.
[22:55] <unggnu> bryce: I guess huge patches should be integrated?
[22:55] <unggnu> *shouldn't
[22:56] <bryce> right
[22:56] <bryce> (generally)
[22:56] <unggnu> so no need for assigning?
[22:59] <bryce> unggnu: right
[23:08] <unggnu> hm, haven't found so much
[23:08] <bryce> ok good.  I did a patrol for quirks and found only one
[23:08] <unggnu> four and one seems to be dirty but was confirmed several times https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/133060
[23:21] <tormod> actually update-manager uses more memory than firefox, lol
[23:22] <tormod> can I trust System Monitor - firefox only 43MB?
[23:22] <tormod> I wonder if I add up those numbers and compare with "free"
[23:36] <unggnu> bryce: another quirk possibility https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/201032
[23:39] <unggnu> and another one https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/200805
[23:40] <tormod> oops that was wrong channel - time for bed QED
[23:42] <unggnu> :)
[23:43] <unggnu> I am not sure with them so I haven't assigned you.
[23:44] <unggnu> I am off too, ciao
[23:55] <bryce> excellent