[04:24] <tlm> Hi all, is anyone available to help with a launchpad API issue? Currently building juju 2.7.1 via launchpad api's. When we review the recent builds via the api we require a 'snap_upload_url' to be returned. However our build scripts are getting an empty string value for this after waiting for a significant amount of time.
[09:11] <cjwatson> tlm: Do you mean store_upload_url?  And how long is significant?
[09:25] <tlm> cjwatson: yeah, almost 2 hours was our longest wait till giving up
[09:26] <wgrant> URLs would be helpful.
[09:26] <cjwatson> tlm: It's asynchronous and it's always possible there's some kind of problem - but yes, specifics please
[09:29] <tlm> the build finishes and is indicated as 'FULLYBUILT', we grab the list of recent builds from launcpad for juju and then keep checking store_upload_url. This goes in a loop till it's found. What can I provide to make hunting the problem down easier ?
[09:29] <cjwatson> tlm: A URL
[09:29] <cjwatson> tlm: To the build in question, for instance
[09:30] <tlm> i'll fire one up and grab it
[09:30] <cjwatson> tlm: Don't you have the previous one?
[09:30] <wgrant> Or a Jenkins job
[09:30] <wgrant> Or something
[09:30] <wgrant> Launchpad builds a *lot* of things for a lots of projects
[09:30] <wgrant> Very hard to identify yours without some details
[09:31] <tlm> yeah no worries
[09:31] <cjwatson> tlm: I'd rather see the previous one than have you fire off a new build; even if the previous one has finished uploading by now, we can check logs
[09:34] <tlm> cjwatson: how is this https://api.launchpad.net/devel/~juju-qa-bot/+snap/juju/+build/796779 ?
[09:53] <wgrant> tlm: It looks like review was stuck in the store. I've hopefully unstuck it, and things might process over the next 10-15 minutes
[09:54] <tlm> ta wgrant, i'll have to kick a new build off just because of a few reasons on our side.  Appears all working. Thanks again for the help.
[12:34] <cjwatson> OK, good


[09:38] <LocutusOfBorg> juliank, hello, you there?
[09:38] <LocutusOfBorg> I tried to upgrade an Ubuntu 20.04 installation and got this
[09:38] <LocutusOfBorg> https://paste.ubuntu.com/p/wh7p4b7ng4/
[09:38] <juliank> LocutusOfBorg: yes
[09:39] <LocutusOfBorg> I'm pinging you because looks suspiciusly related to 1872077
[09:39] <juliank> that's suboptimal
[09:39] <LocutusOfBorg> but I have a recent grub
[09:39] <juliank> LocutusOfBorg: new disk?
[09:39] <LocutusOfBorg> mmm that usb key is not connected
[09:39] <LocutusOfBorg> it was probably connected when the system was installed
[09:40] <juliank> it should have prompted you for the missing disk, though
[09:40] <LocutusOfBorg> I run apt-get dist-upgrade, no graphics
[09:41] <LocutusOfBorg> oh well there is a grub in proposed...
[09:43] <juliank> Well it's a debconf prompt
[09:43] <xnox> i would try dpkg-reconfigure..... but not sure on which package =)
[09:44] <LocutusOfBorg> I tried dpkg-reconfigure, and failed, as well as the one in proposed
[09:45] <LocutusOfBorg> I even tried a grub-install
[09:45] <LocutusOfBorg> sudo dpkg-reconfigure grub-efi-amd64-signed
[09:45] <LocutusOfBorg> fails because not fully installed
[09:47] <LocutusOfBorg> sudo dpkg-reconfigure grub-pc does something
[09:47] <LocutusOfBorg> and dpkg-reconfigure on every grub-package seems to do mostly nothing
[09:48] <juliank> gotta dpkg --configure -a I assume
[09:48] <juliank> well dpkg --configure grub-efi-amd64-signed
[09:48] <LocutusOfBorg> fails with that error
[09:49] <LocutusOfBorg> https://paste.ubuntu.com/p/QGmQWkzPTH/
[09:49] <juliank> Set set -x to /var/lib/dpkg/grub-efi-amd64-signed.postinst and /usr/lib/grub/grub-multi-install and run it again
[09:49] <LocutusOfBorg> sorry for LANG
[09:49] <juliank> and attach a dump of debconf-get-selections | grep grub-efi
[09:50] <juliank> xnox: I wish we were using UUIDs for grub disks rather than the physical ids :/
[09:50] <juliank> Such that I can copy my disk to a new one and it still works
[09:51] <LocutusOfBorg> https://paste.ubuntu.com/p/f6DDkVckST/
[09:51] <juliank> but I just copied the existing code rather than trying to improve it :)
[09:52] <juliank> LocutusOfBorg: It seems to me like you have no ESPs on that system
[09:52] <LocutusOfBorg> I don't even know what esp is
[09:52] <juliank> The EFI system partition
[09:53] <juliank> INPUT critical grub-efi/install_devices_disks_changed
[09:53] <juliank> is skipped
[09:53] <juliank> but then it also had no choices
[09:54] <juliank> one of the partition types should be 0xef
[09:54] <juliank> a FAT partition
[09:54] <juliank> I think what you have here is a weird system with a wrong ESP
[09:54] <juliank> Like, it's a FAT partition that contains ESP contents
[09:55] <juliank> but it has the wrong partition type in the partition table
[09:55] <juliank> some systems can boot from those
[09:55] <LocutusOfBorg> here my mount https://paste.ubuntu.com/p/DkZT39kVqh/
[09:55] <cjwatson> juliank: disks don't have useful UUIDs - filesystems do
[09:56] <LocutusOfBorg> I have a /boot/efi
[09:56] <juliank> cjwatson: hmm yes, for ESPs UUIDs would work, but I copied code that installed to disks/partitions
[09:56] <juliank> LocutusOfBorg: Yes, so you selected that USB stick at one point during upgrading, and that ESP mounted to /boot/efi was migrated to the debconf database too
[09:57] <juliank> But it's not actually a proper ESP
[09:57] <cjwatson> That code was specifically designed for BIOS
[09:57] <juliank> cjwatson: I'm not sure how much it matters, though, because who copies their entire ESP?
[09:57] <juliank> :D
[09:57] <LocutusOfBorg> juliank, I did a upgrade and dist-upgrade without touching anything... do you have an hotfix?
[09:58] <juliank> LocutusOfBorg: Open fdisk, and change the paritition type of /dev/sda1 from 0xb to 0xef
[09:59] <juliank> 0xb is 32-bit FAT, 0xef is ESP (which is also 32-bit FAT, well technically a subset, but who cares)
[10:00] <LocutusOfBorg> well, it worked!!!
[10:00] <LocutusOfBorg> looks like it prompted me for the change and only one selection was available
[10:00] <LocutusOfBorg> now, let me add some background
[10:00] <LocutusOfBorg> we use systemback to install systems easily
[10:00] <juliank> cjwatson: I guess debconf skips multichoice questions with no choices?
[10:00] <LocutusOfBorg> so that might have broken with 20.04 even if really tested
[10:01] <juliank> xnox: So ... I guess we also need to show any VFAT partition on the system, not just proper ESPs
[10:02] <juliank> xnox: Because clearly LocutusOfBorg's system booted from that ESP despite it having the wrong partition type in the partition table
[10:03] <juliank> which raises more questions
[10:03] <juliank> There are hidden 32-bit, hidden 16-bit, and of course 16-bit FAT partitions
[10:03] <juliank> and some more strange partition types
[10:03] <juliank> i found this list https://thestarman.pcministry.com/asm/mbr/PartTypes.htm
[10:04] <juliank> Maybe we need to look at the file system
[10:04] <juliank> rather than the partition
[10:04] <juliank> At least, if that's been a choice previously, it should be shown
[10:06] <juliank> LocutusOfBorg: Could you put the data into a bug report?
[10:06] <juliank> this clearly needs fixing
[10:06] <cjwatson> juliank: Uh, I don't remember.  Do you need me to dig?
[10:07] <juliank> cjwatson: Nah, i was just curious a bit
[10:07] <cjwatson> "Unlike select lists, multiselect questions are visible if there is just one choice."
[10:07] <cjwatson> say the docs
[10:07] <juliank> right, we had no choices at all here which is not a useful choice to have :D
[10:08] <juliank> But that means I miss a prompt for systems that have no suitable partition
[10:08] <cjwatson> They're actually visible if there are zero choices, which seems to me to be a possible bug
[10:08] <juliank> Like "Your system does not have a suitable EFI system partition. Cannot continue."
[10:08] <juliank> Though
[10:08] <juliank> Hmm
[10:08] <juliank> It should ask the _empty question
[10:09] <cjwatson> Oh of course, multiselect obviously has to be visible with one choice because multiselect is more like a set of checkboxes than a radio button or whatever
[10:09] <juliank> yup
[10:09] <juliank> So I need to see why the code never prompted grub-efi/install_devices_empty despite there being no disks found
[10:10] <juliank> Ah
[10:10] <juliank> hmm
[10:18] <LocutusOfBorg> juliank, against which package?
[10:18] <LocutusOfBorg> grub2 right?
[10:18] <juliank> LocutusOfBorg: grub2
[10:18] <LocutusOfBorg> ack, affecting groovy and focal
[10:18] <juliank> yeah
[10:19] <LocutusOfBorg> I'll point this link to the bug report
[10:19] <LocutusOfBorg> https://irclogs.ubuntu.com/2020/10/12/%23ubuntu-devel.html
[10:21] <juliank> LocutusOfBorg: Helpfully it's the first discussion today, even :D
[10:21] <LocutusOfBorg> it is :D
[10:22] <LocutusOfBorg> #1899462
[10:25] <LocutusOfBorg> LP: #1899462
[10:31] <juliank> LocutusOfBorg: thanks
[10:31] <LocutusOfBorg> thanks to you for the great help!
[10:31] <LocutusOfBorg> I admit this seems a serious bug to me, it prevents upgrades...
[10:32] <juliank> ack
[10:33] <juliank> It affects a few people
[10:33] <juliank> But it's obviously not a problem for most
[10:33] <LocutusOfBorg> I don't know if the system was still bootable after this "incomplete upgrade"
[10:33] <LocutusOfBorg> this is why I just set up high severity
[10:33] <juliank> It probably was, yes
[10:33] <LocutusOfBorg> oh this is less worrysome then :P
[10:34] <juliank> The EFI binaries are single binaries, they don't need external modules, and will continue to work if not updated
[10:34] <juliank> Well, except the new shim does not trust old grubs
[10:34] <juliank> um
[10:34] <juliank> old grubs were revoked
[15:01] <seb128> bdmurray, hey, did you have any chance to poke at the retracers issue on 20.10?
[15:15] <bdmurray> seb128: A little bit and then I discovered an issue with the Launchpad retracers which I sorted out. I'll look more at the Error Tracker ones today.
[15:25] <seb128> bdmurray, thanks
[15:27] <seb128> bdmurray, do buckets with a failed retrace get stucked on the status until someone reset them or something or do they keep trying to retrace new reports until they get a successful backtrace?
[15:29] <bdmurray> seb128: They keep retrying for 20.10 as of last week or so - I'd missed that.
[15:31] <bdmurray> seb128: I do see a lot more "Create" links on the errors.ubuntu.com page for 20.10
[15:32] <seb128> bdmurray, right, still not for the top of the list though, still somewhat weird
[15:34] <bdmurray> yeah, gnome-shell has quite a few failures


[08:38] <lool> seb128: Hey
[08:38] <lool> seb128: I think you synced gnome-build
[08:38] <lool> seb128: But it had a SONAME change; the fixed one is in NEW in Debian ATM
[08:38] <lool> Perhaps we should upload a snapshot of it from pkg-gnome?
[08:39] <seb128> hello lool, yes, I didn't expect robster to screw in unstable ;-)
[08:39] <seb128> lool: huats was working on it, he's the one who pointed me the soname change which I pointed to robster
[08:39] <Zuolai> hi, I'd like to have one of the specials keys of my keyboard to launch gvim. There is no such action yet in the keyboard shortcuts settings program - how can I add it?
[08:45] <Zuolai> could someone point me to instructions on how to do this manually?
[08:45] <seb128> mvo: hey, could you look at bug #274565
[08:46] <seb128> Zuolai: that's not an user question chan, try #ubuntu
[08:47] <seb128> mvo: the current comment has a "short read in buffer_copy" error, is that something known?
[08:47] <Zuolai> ok
[08:47] <mvo> seb128: that sounds like a media error
[08:48] <mvo> seb128: but the first report looks different: gconf-schemas: error: You need at least a file to (un)register.gconf-schemas: error: You need at least a file to (un)register.
[08:48] <mvo> eh: gconf-schemas: error: You need at least a file to (un)register.
[08:48] <seb128> mvo: right, I wonder how that's possible, the postinst should be the same for everybody and it lists schemas for sure
[08:49]  * mvo nods
[08:49] <seb128> I hate those upgrade bugs, they almost never makes sense
[08:50] <seb128> mvo: thanks, I'll change the bug to a question, that's not a bug but a local installation issue
[08:50] <mvo> seb128: I added a comment
[08:50] <mvo> seb128: no idea about the one from david
[08:50] <seb128> mvo: thanks
[09:09] <davmor2> quick query on today's iso I was expecting to see Ekiga 3.0 as it is the new default in gnome but it seems to still be 2.0.12 is this likely to change at all?
[09:12] <seb128> davmor2: why did you expect to see something which has not been uploaded to ubuntu?
[09:12] <seb128> davmor2: depends if somebody is wanting to work on ekiga in ubuntu, I've too much to do already and don't use it so I'm not
[09:13] <davmor2> seb128: No it was more reading all about it from gnome reviews etc.  And more kinda assuming than expecting
[09:18] <huats> morning fellows
[09:18] <huats> !
[09:19] <seb128> lut huats
[09:20] <huats> hello seb128
[09:37] <davmor2> guys just found this bug https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/275744
[09:38] <mvo> davmor2: let me have a look
[09:39] <mvo> davmor2: thanks, I think I know what the reason for this is
[09:39] <davmor2> no probs
[09:39] <davmor2> asac: ping
[09:40] <mvo> seb128: I took the "compiz falls back to ini when gconf is not functioning" the other day (was assigned to you) - I guess you don't mind ;) ?
[09:40] <seb128> mvo: dunno why it was assigned to me but thanks for working on this one ;-)
[09:42] <mvo> seb128: I also added local filtering to the package_hook script in apport (just pushed the branch),. then we can just add the bogus one there
[09:42] <mvo> and never see them again
[09:43] <seb128> mvo: how is that different of bug patterns?
[09:43] <asac> davmor2: pong
[09:45] <davmor2> asac: I got an issue with FF on my 19" monitor running at 1440X900 when I first start FF the window extends beyond the top panel
[09:48] <davmor2> asac: www.davmor2.co.uk/ff-size.png
[09:48] <asac> davmor2: interesting
[09:48] <asac> davmor2: this is compiz right?
[09:49] <mvo> seb128: isn't that per package?
[09:49] <asac> mvo: ^^ these issues started to get reported a few weeks ago :/
[09:49] <seb128> mvo: yes
[09:49] <davmor2> asac: compiz is on by default yes it's an all intel machine
[09:50] <mvo> seb128: we could need a global bug pattern or a special handling pattern or something. to say "all report with "short read in buffer_copy"" for example that works on all package. my understanding is that there is currently no global one?
[09:50] <davmor2> mvo: I can confirm that you fix for xapian works by the way :)
[09:50] <mvo> seb128: but maybe that is a better approch, just adding one
[09:50] <asac> mvo: how can we track down a regression window?
[09:50] <mvo> davmor2: great, thanks
[09:51] <asac> (for compiz)
[09:51] <davmor2> breakfast I'll be back in a bit :)
[09:51] <mvo> asac: compiz has not changed in the last 6 weeks
[09:52] <seb128> mvo: oh, that was about the buffer_copy thing, I was not in the right context ;-) Yes, that makes sense to have those, out of space, etc handled directly locally rather than having to get online datas, etc
[09:52] <mvo> davmor2: could you please install the packages from "deb http://ppa.launchpad.net/compiz/ubuntu hardy main" and see if that fixes the issue?
[09:52] <mvo> seb128: aha, ok :)
[09:52] <mvo> seb128: I was wondering if I had overlooked something obvious :)
[09:53] <mvo> asac: do you see this window problem as well on your machine?
[09:57] <asac> mvo: unfortunately not. but there have a been a few reports of this over the lats weeks
[09:57] <asac> mvo: mdz has it itoo
[09:58] <mvo> asac: ok, I will wait for davmor2 to test the 0.7.8-release version first
[09:58] <asac> mvo: it appears to be related to dual monitor setups (if not related, at least easier reproducible)
[09:59] <asac> well ... not sure. lets wait for davmor
[10:02] <mvo> asac: right, I was suspecting that (dual monitor)
[10:02] <mvo> that or driver or both
[10:04] <asac> mvo: just a guess. i think its easier to reproduce when going down from a high screen resolution to a lower one
[10:04] <asac> (thats what i remember someone said)
[10:04] <davmor2> mvo, asac: back
[10:05] <mvo> davmor2: what setup do you use (dual screen? if so, what resolutions?)
[10:05] <davmor2> mvo: single screen 1440X900
[10:05] <mvo> davmor2: what driver?
[10:06] <davmor2> intel
[10:06] <mvo> seb128: could you please "bzr add debian/patches/96_gnome_appearance_properties_doesnt_crash.patch" and then bzr commit; bzr push in your gnome-control-center branch? if you don't have it on disk anymore don't bother, I download/add it myself
[10:07] <mvo> davmor2: thanks :) next thing would be to test the 0.7.8 release from the compiz PPA
[10:07] <seb128> mvo: I did that? and I did a new version update since which removed the patch since the new version has the change no?
[10:07] <davmor2> what's the ppa address ?
[10:08] <mvo> seb128: oh, sorry - I misread the changelog
[10:08]  * mvo whistles innocently
[10:08] <seb128> mvo: or did I screwed up on bzr again?
[10:08]  * seb128 verifies
[10:08] <mvo> seb128: I think its all fine
[10:08] <mvo> davmor2: could you please install the packages from "deb http://ppa.launchpad.net/compiz/ubuntu hardy main" and see if that fixes the issue?
[10:08] <seb128> mvo: https://code.edge.launchpad.net/~ubuntu-core-dev/gnome-control-center/ubuntu is uptodate so I think it's alright ;-)
[10:09]  * seb128 hugs mvo
[10:09]  * mvo hugs seb128
[10:09] <davmor2> mvo: hardy main and not intrepid main?
[10:10] <mvo> davmor2: eh, sorry - intrepid
[10:11] <davmor2> mvo: 10 updates does that sound about right?
[10:11] <mvo> davmor2: yes
[10:12] <seb128> mvo: having a fix for the set keyboard default crasher?
[10:13] <mvo> seb128: I'm currently working on this
[10:14] <davmor2> mvo: rebooted and firefox is the same
[10:15] <asac> davmor2: how do you reproduce?
[10:15] <mvo> davmor2: ok, thanks. could you please file a bug about it? I will change my resolution to see if I can reproduce it here
[10:15] <mvo> davmor2: is it just ff? or does e.g. epiphany has the same problem?
[10:16] <davmor2> asac: I just open FF
[10:16] <davmor2> mvo: I'll install it now and see
[10:16] <asac> davmor2: in maximized window mode?
[10:17] <davmor2> asac: no just as it opens out of the box
[10:18] <davmor2> asac: the minute you max it or re-size so it fits it's fine
[10:18] <mvo> davmor2: that is on a fresh install or on your home machine?
[10:19] <davmor2> mvo: fresh install of todays iso
[10:19] <mvo> davmor2: thanks
[10:19] <mvo> pitti: if the guest session fails, is there more log information beside Xorg.20.log ?
[10:20] <asac> davmor2: so if you resize it now to proper size, stop it and start it again its ok?
[10:21] <davmor2> asac: 2 ticks
[10:22] <davmor2> mvo: epiphany starts full screen no issues
[10:22] <mvo> davmor2: thanks
[10:23] <pitti> mvo: when does it fail?
[10:23] <pitti> mvo: guest session has .xsession-errors, but that's wiped after it ends,  of course
[10:23] <davmor2> asac: Yes
[10:23] <pitti> mvo: if it fails to startup, you can run /usr/share/gdm/guest-session/guest-session-launch from a terminal (as normal user)
[10:23] <mvo> pitti: I suspect its something to do with my nvidia or somesuch, but I would like to check what exactly goes wrong
[10:23] <mvo> pitti: thanks, I'm trying this now
[10:24] <davmor2> asac: I just reduced the window size by about quater - half an inch and it sits on the desktop nicely.
[10:25] <davmor2> asac: If I delete the .mozilla folder from home and open afresh though it is off the desktop again.
[10:25] <mvo> pitti: hm, gdmflexiserver and then  "OK :20" and then it returns. is there a way to preserve files in the guest session somehow? or could I hack it up easily?
[10:26] <mvo> pitti: nevermind, I think I found the guest-session-cleanup.sh and will modify that
[10:26] <davmor2> mvo, asac: Would you like me to open a new bug on the FF issue then?
[10:27] <mvo> davmor2: please do, when I get the guest session going again I will see if I can reproduce it
[10:28] <davmor2> mvo: just move .mozilla somewhere other than home and open it up fresh :)
[10:33] <mvo> pitti: I found it, bug #275764
[10:34] <pitti> mvo: uh, *dash*isms?
[10:34] <mvo> pitti: it seems to be one :)
[10:34] <mvo> its the first one I have seen so far!
[10:35] <pitti> mvo: thanks, will fix ASAP
[10:35] <mvo> no problem, its just a issue on non default setups anyway
[10:36] <davmor2> mvo, asac: there's already an open bug about this is there any info I can add to it for you?  https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/257947
[10:36] <mvo> davmor2: I can reproduce it just fine
[10:40] <davmor2> mvo: just to confirm when you switch comiz off FF appears as intended.  So this will almost certainly only effect machines where compiz is on out of the box :)
[10:40] <asac> there are more dupes: bug 257947 bug 275358 bug 252317
[10:40] <mvo> yeah, the issue seems to be that ff default size is ~900px
[10:40] <mvo> and compiz does not tell it that it can't have this size (metactiy does)
[10:41]  * mvo wonders what he can do when he locked the guest session via gnome-screensaver
[10:43] <asac> davmor2: do you have a setup where screen resolution is higher than 900 and that works with compiz?
[10:43] <asac> (my main system doesnt have compiz)
[10:44] <davmor2> asac: my main monitor goes higher but you'll need to give me some time to swap them over
[10:54] <davmor2> asac, mvo: http://www.davmor2.co.uk/ff-oversize.png
[10:59] <mvo> davmor2: right, I see this here too
[10:59]  * mvo scratches his head
[11:02] <asac> bug 252317
[11:02] <asac> states that screen.availHeight gives the wrong value
[11:03] <asac> mvo: so somehow compiz gives ffox the availHeight without substracting the panels
[11:03] <mvo> asac: what function does ff use to get it (or what file of the code do I need to look at)?
[11:04] <asac> mvo: will take a bit to find this out ... :) i remember that i had wierd issues with that in midbrowser
[11:04] <asac> (e.g. matchbox behaved differently than metacity)
[11:05] <mvo> asac: ok, thanks. I grep the source and see if I can find anything
[11:09] <asac> mvo: AvailRect = mRect = nsRect(0, 0, gdk_screen_width(), gdk_screen_height());
[11:10] <mvo> asac: in what package is that? not in firefox itself?
[11:10] <asac> mvo: thats in xulrunner-1.9
[11:10]  * mvo apt-get sources that
[11:10] <asac> mvo: you can better search and navigate in mxr.mozilla.org
[11:10] <asac> mvo: http://mxr.mozilla.org/mozilla/
[11:11] <asac> mvo: that code is in nsScreenGtk.cpp
[11:11] <mvo> thanks asac
[11:11] <davmor2> asac, mvo: give me a ping if you sort it and you want it testing :)
[11:11] <asac> http://mxr.mozilla.org/mozilla/source/widget/src/gtk2/nsScreenGtk.cpp#147
[11:11] <asac> mvo: ^^
[11:15] <mvo> asac: thanks, I look into it
[11:15] <asac> mvo: not really sure if the availRect boundaries are the problem or how ffox sets the position size .. most likely it uses a gdk_window function to do that
[11:17] <davmor2> asac: it sits nicely on the bottom panel
[11:17] <mvo> asac: hm, right. it might be as simple as that it uses gtk_window_move(0,0)
[11:18] <asac> mvo: shouldnt window_move do the right thing if you dont use a special window type?
[11:19] <asac> (window type like gnome-panel ;))
[11:20] <mvo> asac: its the window managers job to deal wit hthat, but I think there is some interaction going a  bong somewhere
[11:22] <asac> mvo: http://mxr.mozilla.org/mozilla/source/widget/src/gtk2/nsWindow.cpp#3503
[11:22] <asac> thats the place where "Move" is implemented
[11:22] <asac> err ... that was NativeResize ... http://mxr.mozilla.org/mozilla/source/widget/src/gtk2/nsWindow.cpp#600
[11:22] <asac> thats move
[11:34] <mvo> asac: is there a way to get all the nice LOG() stuff without recompiling?
[11:44] <davmor2> mvo: do you have intel gfx on your machine?
[11:45] <asac> mvo: depends on what LOG that is
[11:46] <asac> mvo: you can get _all_ log that is available without special build flags with:
[11:46] <asac> NSPR_LOG_MODULES=all:5
[11:46] <asac> err
[11:46] <asac> NSPR_LOG_MODULES=all:5 firefox
[11:46] <asac> you can also say NSPR_LOG_FILE=/tmp/my.log
[11:47] <asac> but i guess there will be far too muhc logging then
[11:48] <asac> so try: NSPR_LOG_MODULES=widget:5
[11:49] <asac> (thats the output with LOG(...)
[11:49] <asac> for LOGDRAW you can append ,widgetDraw:5
[11:50] <asac> e.g. NSPR_LOG_MODULES=widget:5,widgetDraw:5 firefox
[11:50] <asac> mvo: ^^
[11:51] <asac> i guess thats more than enough ;)
[11:59] <davmor2> I got an issue with screensaver/power manager/compiz/intel driver on my intel box, in that, the screensaver kicks in fades to black but as soon as it is black triggers back to the desktop again I'm not sure which of the 4 things is causing the issue though as I don't get it on my nvidia/amd 64 system
[12:02] <davmor2> how can I lower down which is the cause of the issue?
[12:03] <asac> davmor2: disable compiz on your intel system - to see if its compiz
[12:04] <asac> related.
[12:23] <asac> mvo: maybe look at bug 240736 too
[12:23] <asac> mvo: the window is in a wierd tstate there : unmaximize + resize are enabled
[12:25] <davmor2> asac, mvo: it's compiz stopping the screensaver kicking in properly
[12:43] <davmor2> mvo: I've re-opened this bug and tagged it as compiz is that okay https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/253367
[12:47] <mvo> davmor2: thanks, I check that out
[13:09] <huats> seb128: the patch you provided in bug 274398
[13:10] <huats> is aiming to remove the bdeps on the libgdl-gnome-1-0 right ?
[13:11] <seb128> huats: I didn't provide a patch in any bug
[13:11] <huats> This bug was fixed in the package gnome-python-extras - 2.19.1-0ubuntu9
[13:11] <huats> ---------------
[13:11] <huats> gnome-python-extras (2.19.1-0ubuntu9) intrepid; urgency=low
[13:11] <huats>   * debian/patches/80_use_new_gdl.dpatch:
[13:11] <huats>     - correctly build using the gdl version (lp: #274398)
[13:11] <huats>  -- Sebastien Bacher<EMAIL_ADDRESS>Fri, 26 Sep 2008 15:43:55 +0200
[13:11] <seb128> huats: that's an upload
[13:11] <seb128> not a patch
[13:12] <huats> I know
[13:12] <huats> but there is a file debian/patches/80_use_new_gdl.dpatch which is a patch :)
[13:12] <huats> (I might have used a short naming)
[13:12] <seb128> huats: the patch is to fix the build using the new gdl
[13:13] <huats> isn't it also necessary to remove the search in the configure.ac for gdl-gnome-1.0 ?
[13:14] <seb128> huats: dunno, it built fine and I've too busy to look at something which is not broken
[13:15] <huats> ok I undertand
[13:15] <huats> thanks seb128 :)
[13:15] <seb128> huats: the current version built fine using the current gdl
[13:15] <seb128> you're welcome ;-)
[13:15] <huats> that is the main thing (that it builds fine)
[13:45] <didrocks> hi seb128!
[13:45] <didrocks> seb128: some work to achieve that will be uploaded after the beta freeze? (swfdec is stille in debian NEW)
[13:45] <seb128> hey didrocks
[13:46] <seb128> didrocks: no, beta is frozen
[13:46] <didrocks> s/stille/sill :)
[13:47] <seb128> didrocks: for most of the week yes
[13:48] <didrocks> seb128: yes, I was just thinking that we could prepare some stuff to upload after the freeze
[13:49] <seb128> didrocks: why not, my list is pretty empty though, we did a good job to update GNOME before the freeze and they don't roll tarballs every week or that would be lot of work for everybody ;-)
[13:49] <seb128> didrocks: this week is a good one to do CD testing, bug triage and start fixing bugs for intrepid
[13:50] <didrocks> seb128: ok, will try to reinstall my VM from scratch and test it
[14:52] <pitti> seb128: ah, *phew*; the f-spot error just seems to be an URL quoting problem; while --import /tmp/gph works, --import /tmp/gphoto2-Medium\ auf\ usb%3A005\,014/ fails
[14:53] <pitti> that should be reasonably easy
[14:53] <seb128> ah good
[14:55] <pitti> and there are a couple of relevant upstream bug fixes, too
[14:55] <pitti> so I think I can handle this
[14:57] <seb128> pitti: ideally we should update to the new f-spot 0.5
[14:58] <mvo> hm, no video display still :/
[14:58] <mvo> but otherwise the improvements look quite impressive
[14:59] <seb128> same rational I had in hardy
[15:00] <seb128> f-spot is a buggy piece of software and updates are often a win over the current situation
[15:09] <seb128> grrra, something close xchat-gnome tabs when I switch workspace or something
[15:43] <mvo> pitti: if you have a moment, could you check lp:~mvo/apport/mvo ? you may want to change it in a way that the filtering goes into package_impl or that it is solved via some sort of global bugpattern - I'm open for discussion here of course :)
[15:55] <pitti> seb128: yay f-spot upstream closing bugs which aren't fixed
[15:55] <pitti> mvo: will do later
[15:55] <seb128> pitti: oh?
[15:57] <pitti> seb128: gnome bug 433829, reopened with a comment
[15:57] <seb128> ok
[16:14] <seb128> mvo: I think my tab closing issue is a compiz bug
[16:14] <mvo> seb128: what tab closing issue?
[16:15] <seb128> mvo: I keep closing xchat-gnome tabs for some days
[16:16] <seb128> mvo: so, go to workspace 1, open an application, click on it so it has the focus, switch to an another workspace which has something open a focus that, switch back to workspace 1
[16:17] <seb128> mvo: I think it used to focus the only dialog which is on this workspace, now the focus is still on the workspace which is not displayed
[16:17] <seb128> I often switch to a workspace where I've xchat-gnome, switch back to some other workpace using the keyboard and start typing
[16:17] <seb128> I expect the only thing being on screen to have the focus and I think it used to work this way
[16:18] <seb128> does that makes sense somehow?
[16:18] <mvo> it does, I will try to reproduce in a bit
[16:19] <seb128> mvo: I'll try using the intrepid compiz later, I've the ppa version right now and don't want to close my session
[16:21] <mvo> seb128: thanks
[16:21] <mvo> let me know what you find
[16:23] <seb128> try now, brb
[16:42] <seb128> re
[16:43] <pitti> seb128: bwah; so I fixed the import crash in f-spot, and it actually works now; but it sucks
[16:43] <seb128> pitti: f-spot sucks that's not really new :-(
[16:43] <pitti> seb128: it's slow as hell (I suppose it reads the full pics for getting the thumbnails) and it crashes if I import them twice, and I don't get the "target dir" button, etc.
[16:43] <pitti> I don't think I can fix all that by the beta
[16:43] <seb128> just push what you fixed now, that will do for beta
[16:44] <seb128> photo import is not the most import thing to try or get feedback on now
[16:44] <seb128> mvo: the intrepid version doesn't have the bug
[16:44] <pitti> the dialog I get for libgphoto is magnitudes faster and works much better
[16:44] <pitti> seb128: ok, I'll upload this
[16:45] <pitti> seb128: but it seems that using the fuse path takes away too much knowledge from f-spot
[16:45] <pitti> (uploaded)
[16:46] <seb128> pitti: so maybe we should reconsider the approch and disable the gvfs gphoto backend again as we did in hardy?
[16:46] <pitti> seb128: ideally we would only mount it when the user chooses to open it
[16:46] <pitti> (in nautilus)
[16:46] <pitti> so that we can keep the best of both worlds
[16:47] <seb128> pitti: that's easy to do, we just have to disable the gphoto automounting
[16:47] <pitti> seb128: or, of course, someone fixes f-spot to properly talk gvfs :)
[16:47] <seb128> pitti: that still create issues for people who double click on it and then try to use f-spot
[16:47] <pitti> seb128: but would that still mount the camera if you try to open it in nautilus? ("Browse files")
[16:47] <seb128> pitti: yes
[16:48] <seb128> hey Keybuk
[17:29] <mvo> asac: compiz upstream fixed the ff screensize issue already, they are rockstars
[17:29] <mvo> ^--- davmor2_away
[17:29] <mvo> now I just need to roll new packages :)
[17:31] <asac> mvo: thats really awesome
[17:31] <mvo> asac: I milestoned it and will add it tomorrow
[17:31] <asac> mvo: do you know which commit fixed that?
[17:31] <mvo> Fixed in commits 3dd149ce5c465cf9b068aeb0bfdeb207907a836c and
[17:31] <mvo> 633385e5e54147e750c6ca5a179f803373ab3e3e.
[17:32] <asac> mvo: lol ... do you have a link ;) ... for someone like me (a compiz foreigner without a visa ) ?
[17:32] <mvo> http://gitweb.compiz-fusion.org/?p=compiz;a=log;h=45caca2220f75bfd20074c217ebee10825413547
[17:32] <asac> cool
[17:32] <mvo> eh
[17:32] <mvo> sorry, wrong paste
[17:32] <mvo> http://gitweb.compiz-fusion.org/?p=compiz;a=commitdiff;h=633385e5e54147e750c6ca5a179f803373ab3e3e
[17:32] <asac> i think i found it ;)
[17:33] <mvo> ok
[17:34] <asac> mvo: ok ... so that retroactively resizes/replaces the window?
[17:34] <asac> or is the workarea the root window from where the coordinates are relative?
[17:35] <mvo> I think it just overrides what ff wants, but that should be no problem, the window manager is free to do that
[17:36] <mvo> seb128: I just tried what you described with compiz, one open window in the each workspace, switch and check were the keyboard focus is
[17:37] <mvo> but no luck, seems to be switching it for me to the new window
[17:37] <seb128> mvo: no, it's
[17:37] <seb128> - go to workspace one, open gedit, click in the text area making sure the dialog has the focus (decoration color shows you that for example)
[17:38] <seb128> - click on the workspace switcher to an another workspace
[17:38] <seb128> workspace which has something open
[17:38] <seb128> does the dialog open gets the focus, ie is it colored, or do you have to click on it?
[17:38] <seb128> I've to click on it here
[17:39] <mvo> as soon as I switch the dialog in the new workspace gets the focus (with 0.7.8)
[17:39] <mvo> maybe somethign with the focus model? do you use click-to-focus or focus-follow-mouse?
[17:39] <seb128> click to focus
[17:39] <seb128> which is the default
[17:40]  * mvo nods
[17:40] <seb128> you?
[17:40] <mvo> I tried both
[17:40] <mvo> let me restart my session
[17:40] <seb128> bah ok
[17:40] <mvo> hm, can't - kvm still running
[17:40] <seb128> mvo: ok thanks
[17:40] <seb128> mvo: no hurry, did you add patches to the ppa recently?
[17:40] <mvo> I will do it after dinner or tomorrow
[17:40] <seb128> the version I was running is one week old
[17:40] <mvo> no :/
[17:41]  * mvo scratches his head
[17:41] <mvo> maybe (but very unlikely) driver dependant?
[17:41] <seb128> mvo: maybe try using a new user?
[17:41] <mvo> exxcellent idea
[17:41] <seb128> mvo: I doubt of it, that's working using the intrepid version
[17:41] <mvo> right
[17:42] <seb128> and video driver and input have not a lot in common usually
[17:43] <mvo> no, same
[17:43] <seb128> mvo: same what?
[17:43] <mvo> seb128: do you have with a fresh user too?
[17:44] <seb128> mvo: well, I don't want to close my session and opening a new session will not use compiz, will it?
[17:44] <mvo> the guest session works for me
[17:44] <mvo> yeah, only nvidia can use compiz in the guest session currently
[17:44] <seb128> mvo: well, second session is not dri capable so no compiz no?
[17:44] <seb128> I'm using intel
[17:45] <mvo> yeah, you would have to create a new user I guess, not very urgent, just let me know if you try it
[17:45] <seb128> mvo: I'll try again later, but I was closing tabs by mistake for a week so it's pretty reliable here
[17:45]  * mvo nods
[17:45] <seb128> mvo: I'll try after dinner
[17:45] <mvo> and you get it always when you follow the instructions posted?
[17:46] <seb128> well, it took me a while to notice why I was closing tabs in xchat-gnome
[17:46] <seb128> I always have xchat-gnome maximized on workspace 3
[17:46] <seb128> and epiphany on some other workspace
[17:47] <seb128> and I switch between workspaces using alt-n
[17:47] <mvo> heh :) I can imagine that was puzzeling
[17:47] <seb128> so I do work on epiphany
[17:47] <seb128> alt-3 to read IRC
[17:47] <seb128> click with the mouse on a tab to read it
[17:47] <seb128> type something
[17:48] <seb128> alt-1 to go back to the browser
[17:48] <seb128> ctrl-W to close the tab once I'm done reading it
[17:48] <crevette> hello
[17:48] <seb128> and that closes the xchat-gnome tab
[17:48] <seb128> lut crevette
[17:49] <crevette> seb128: I had an error while upgrading to capplets-data 1:<IP_ADDRESS>-0ubuntu1 few minutes ago
[17:49] <crevette> http://dpaste.com/81225/
[17:50] <mvo> seb128: ha! I can reproduce it now, when I do it via keypress *and* release the keys immediately (before the animation finishes)
[17:50] <mvo> hrm, now that does work again
[17:50] <mvo> how strange
[17:51]  * mvo can't find a pattern
[17:52] <seb128> crevette: good so you can open a bug on the buggy translations on bugzilla.gnome.org
[17:52] <seb128> mvo: oh, I always release the key before the end of animation
[17:52] <seb128> mvo: I pretty quick at this alt-n thing and the animation not so ;-)
[17:53] <crevette> seb128: this is a translation problem?
[17:53] <seb128> crevette: yes
[17:55] <seb128> crevette: control-center.schemas, one of the translations has no [] around the list
[17:56] <crevette> i'll try to open it, I'm carrying my son
[17:57] <seb128> crevette: oh, congratulations ;-)
[17:57] <crevette> tx
[17:57] <crevette> you didnt know it
[17:57] <crevette> he's born near 1 month ago
[17:59] <seb128> you didn't say anything
[17:59] <seb128> or that was during my holidays
[17:59] <crevette> It's annonced on #gnomefr
[17:59] <crevette> :)
[17:59] <seb128> crevette: is everybody doing great then? ;-)
[17:59] <seb128> crevette: I'm not on that channel ;-)
[18:00] <crevette> yep
[18:00] <crevette> he is not growing that much
[18:00] <crevette> he 's a bit lazy
[18:01] <crevette> but it's better these days
[18:03] <seb128> ok
[18:04]  * crevette is taking a video
[18:04] <crevette> seb128: http://dl.getdropbox.com/u/184567/2008-09-28-191301.ogv
[18:04] <crevette> :)
[18:06] <seb128> I'll watch it later the intel video driver seems to not like compiz or something
[18:06] <crevette> compiz is bad
[18:06] <crevette> :)
[18:06] <crevette> okay
[18:06] <seb128> sometimes ;-)