[00:03] <Haunted330> This channel is closed. You are going to have to leave.
[00:03] <xrandr> Hi there.  I have an ubuntu 18.04 server, and used netplan to apply a set of static ip addresses. However, when i use ifconfig, I do not see the ips being bound to my server.
[00:04] <Haunted330> This channel is closed. You are going to have to leave.
[00:04] <Haunted330> We reopen at 8am CST.
[00:05] <teward> !ops | Haunted330 trollig the channel
[00:05] <Haunted330> !ops Everything is good
[00:05] <Haunted330> Leave the ops alone please.
[00:05] <Haunted330> Im just doing my job
[00:06] <hggdh> Haunted330: ok, then goodbye
[00:06] <Haunted330> yep, good bye
[00:07] <teward> hggdh: thanks.
[00:08] <hggdh> teward: yw
[00:08] <teward> xrandr: so `sudo netplan apply` doesn't apply the IPs?
[00:09] <teward> trying to make sure it's just a case of them not applying or whether Netplan's just derping at some point, or whether something else is up.
[00:10] <teward> seeing your config would be nice as well, xrandr, since it might be your config.  (cc TJ- since we said in #ubuntu to move here)
[00:10] <xrandr> sure
[00:10] <xrandr> one moment and i will pastebin it
[00:10] <xrandr> :q
[00:11] <xrandr> https://pastebin.com/3aR4J8B9
[00:12] <TJ-> xrandr: what does "ip addr show dev enp2s0" report?
[00:12] <xrandr> teward: and to answer your first question, it does not apply it
[00:13] <xrandr> https://pastebin.com/zt7L4RcM
[00:13] <TJ-> xrandr: also, check the service for clues "journalctl -u systemd-networkd"
[00:13] <TJ-> xrandr: looks correct to me, where is the problem?
[00:14] <xrandr> ifconfig doesn't report the ips, and also, I can't ping them. No firewall is currently active either (server was just deployed)
[00:14] <TJ-> xrandr: you've only assigned a single IPv4 address to the interface
[00:14] <sarnold> don't worry so much about ifconfig, it doesn't know networking as well as ip does
[00:15] <xrandr> TJ-: I thought by specifying the /29 it would add the range
[00:15] <TJ-> xrandr: <IP_ADDRESS> pings OK
[00:15] <xrandr> .170-.174
[00:15] <TJ-> xrandr: No, it assigns the single address in the /29 sub-net
[00:15] <xrandr> Well, that could be my issue lol.
[00:16] <TJ-> I'm not sure netplan knows how to assign all the possible IP addresses of a sub-net to a single interface
[00:16] <xrandr> How would I go about assigning the other ips to the server?
[00:16] <teward> add the addresses individually
[00:16] <teward> let me pull an example...
[00:16] <teward> I think i wrote one for the examples for netplan...
[00:16] <sarnold> see e.g. https://netplan.io/examples#multiple-addresses-on-an-interface
[00:16] <teward> *pulls up historical git commits*
[00:16] <teward> ohey that one
[00:17] <teward> i added the section underneatn that one ;P
[00:17] <teward> xrandr: you have to define each of the addresses.  The /29 is just to specify the subnet mask, it doesn't set all the addresses up (and is relevant to determining proper Broadcast and Gateway address)
[00:17] <teward> so you'd have 170/29, 171/29, etc. etc.
[00:18] <teward> *salts sarnold*
[00:20] <xrandr> Ah there we go
[00:20] <TJ-> It would be nice to be able to do ranges :)  "addresses: [ <IP_ADDRESS>-177/29 ]"
[00:20] <xrandr> thank you all so much
[00:22] <teward> TJ-: indeed.  that's a proposal to suggest to cyphermox
[00:24] <TJ-> teward: I might find some time to attempt a patch but I suspect it'd be a rabbit-hole. Parsing is easy, figuring out the conrrect way to render it not so
[00:26] <teward> yep.
[00:26] <teward> hence why i said propose it in the netplan project and let them gauge interest/implementation
[00:26] <teward> it'd be tricky
[00:29] <TJ-> systemd-networkd is just a case of multiple Address= entries (I wonder what the limit is)
[00:30]  * TJ- stiffles a giggle
[00:30] <TJ-> It could get to be fun for IPv6
[00:31] <teward> TJ-: if you need more than 100 specific addresses added... it's being done wrong lol
[00:37] <TJ-> teward: you're reminding me of the famous 'never need more than 640KB' meme!
[00:38] <TJ-> teward: how can I have an IP-addressable display if the host can't have mor than 100 IP addresses?
[00:38] <teward> :P
[00:40] <TJ-> that brings up and interesting question - how *did* the 75-internet's worth of IPv6 address space get decoded and mapped - presumably it'd have to be a userspace network stack
[07:07] <lordievader> Good morning
[12:08] <Raboo> Hi guys
[12:09] <Raboo> I have a strange issue on two of my Ubuntu 16.04.5, i have biosdevname package installed, but still my interfaces are named eno1/eno2
[12:10] <Raboo> I was under the conception that if you have biosdevname installed, predictable name would be applied
[12:19] <rbasak> Raboo: only if your BIOS actually provides device names.
[12:19] <rbasak> That was only a Dell thing and only for a while AFAIK.
[12:21] <Raboo> hmm, it is a dell server :-)
[12:22] <Raboo> rbasak is there a way to see if the bios provides a device name?
[12:23] <Raboo> but it's quite strange, cause when installing the node we use a centos image, there I believe the device names was em1/em2
[12:23] <Raboo> So i guess the whole bios part is working
[12:25] <Raboo> Yup, the devices was named em1/em2 when in centos
[12:26] <rbasak> Raboo: https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038761.html is a good writeup which hopefully will help you pin it down
[12:28] <rbasak> "70-persistent-net.rules trumps [biosdevname] trumps [ifnames]"
[12:30] <Raboo> yes, but there is no 70-persistent-net.rules
[12:31] <Raboo> in that e-mail it says about ifnames "Debian and Ubuntu disable this by
[12:31] <Raboo> default"
[12:32] <Raboo> so unless that has changed between Ubuntu 16.04.4 and 16.04.5, I should be getting em1/em2
[12:49] <Raboo> running `biosdevname -i eno1` returns a blank
[12:52] <rbasak> 16.04.4 likely had a different kernel to 16.04.5. You could try switching kernels.
[12:52] <rbasak> That is entirely a guess, to be clear.
[12:58] <leftyfb> Raboo: I know you said you have the package insalled, but have you tried putting biosdevname as one of your kernel parameters?
[13:01] <Raboo> leftyfb nope, it should be enabled by default, you usually put biosdevname=0 to turn it off
[13:02] <Raboo> Maybe it's a bios bug, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1578141
[13:09] <Ool> isn't it: GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0" to have the old name ?
[13:09] <Ool> after a update-grub of course
[13:15] <Raboo> well I want biosdevname=1
[13:15] <Raboo> i want em1/em2
[13:18] <Raboo> `biosdevname -d` reports em1 for both eno1 and eno2
[13:18] <Raboo> so it could be a similar bug with the launchpad link i pasted
[13:19] <Raboo> or it could be the mellanox driver, haven't really used mellanox nic before
[13:22] <Raboo> this sucks
[13:27] <rbasak> Raboo: you could manually override to the names you would get by biosdevname but without biosdevname as a workaround.
[13:29] <Raboo> rbasak ok, by adding a 70-persistent-net-rules file?
[13:50] <rbasak> Raboo: right
[15:05] <Raboo> well I found a bug that matches my case more.. https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1535045
[15:07] <Raboo> very little hope on this getting fixed, the bug was filed 3 years ago
[15:08] <Raboo> Anyone know Brian Fromme?
[15:23] <THKitten> well, this is fun. I've got a diaspora server up, and a mastodon server up on my ubuntu server. Apparently both of them are using the same f*$#@$ing redis server, so sidekiq is giving me the finger because each is trying to read the other's database queries, and they can't understand them, so they toss them, therefore, I lose posts.  Suffice to say, I'll ask the clearly better support team, you guys with Ubuntu. Any thoughts here on how I can get both applications to use their own redis database?
[15:24] <TJ-> THKitten: containers might be the quick way - separate them
[15:24] <lordcirth> THKitten, well, this may be overkill for your use case, but at work I would put each in an LXC container. You could also look at running 2 redis servers on different ports and changing the redis port of at least one service
[15:25] <THKitten> I'm relatively new to this, it looks like containers might be the way to go, but I don't have a clue how to do that. I mean ffs diaspora's setup is complex enough as is without screwing with it. It might be better to stick mastodon in its own container and leave diaspora be
[15:28] <TJ-> THKitten: yes, only one needs to move :)
[15:28] <lordcirth> THKitten, apt install lxc lxc-templates && lxc-create -n mastodon -t ubuntu
[15:28] <lordcirth> Actually, you might want to use the newer LXD tools
[15:29] <lordcirth> We haven't moved to those yet, but they are nice
[15:29]  * THKitten bangs head on desk
[15:30] <THKitten> I hate this. Apparently the main dev for diaspora told me this wouldn't work "on the same server" in october, but I dismissed it.  KNOWING other platforms use similar tools to them? fffffff
[15:31] <lordcirth> It could be that they are assuming that everyone will use containers or VMs anyway
[15:32] <Raboo> would #ubuntu-devel or #ubuntu-bugs be a better channel to find someone to squash the bug?
[15:33] <THKitten> it looks like containers it is. is there a youtube video instructional that can walk me through everything I need to know about containers?
[15:33] <THKitten> is 'docker' one of these containers?
[15:33] <teward> Raboo: neither.  #ubuntu-bugs is for triage, #ubuntu-devel would bring attention to the bug but the package is in Universe since Xenial so unless someone *really* wants to patch it...
[15:33] <teward> it's probably not going to get attention
[15:33] <TJ-> THKitten: yes
[15:34] <lordcirth> THKitten, docker is a container system, but you might find LXC/LXD easier, as it's more like a normal server
[15:34] <Raboo> teward what can I do then? Cause a patch have been available forever and the bugreport has no activity since 2016.
[15:36] <THKitten> awesome, mastodon dev is far more helpful and friendly than diaspora dev. Apparently mastodon has a redis_namespace option, so let's try that
[15:37] <lordcirth> THKitten, that sounds like a good solution too
[15:38] <THKitten> it's a far better solution than the "mastodon and diaspora won't work on the same server" that diaspora dev gave to me -_-
[15:39] <TJ-> this is what happens when you have more Dev than Ops !
[15:40] <THKitten> I already feel like this dev doesn't like me, he and I have gotten into so many arguments, all because he's an aggressive ass
[15:49] <THKitten> ok guys, I'm gonna give this a shot....here's what I'm gonna do, but I'm gonna need some help (like, if you can essentially hold my hand, I'd super appreciate that, because this is TOTALLY out of my realm of comfort and skill).
[15:50] <THKitten> I'm going to setup two redis databases in their own docker container and have them hosted on different ports
[15:50] <THKitten> then configure each platform to use that port for their redis databases
[16:28] <teward> Raboo: i saw your ping, apologies I died shortly thereafter I had to do some emergency system reboots on my bouncer for maintenance.  I'm not sure what the 'patch' is or the established 'solution' will be, so i'll have to take a look, it's possible we'd have to look into a better solution for this, but it's not a package on my radar at present, nor is that bug, and I don't see a patch specified in the bug that'd be used to fix it
[16:29] <teward> Raboo: what's the target release you're trying to make this work on?
[16:29] <teward> Xenial?  Bionic?  Trusty?
[19:59] <theGoat> so i have an ubuntu 14.04 server vm running on esxi.  and when i reboot it, it always fails on bringing up the network interfaces, once the vm is booted, i can log in and bring up the interfaces with ifconfig, and i can't figure out why.  everything looks good with the interfaces config
[20:00] <TJ-> Finally figured out how to bind entire /massive/ subnets to the host. "ip [-4|-6] route add local network/prefix dev lo" ... can now make my IPv6 addressable display :)
[20:00] <sarnold> TJ-: lol
[20:02] <sarnold> TJ-: btw https://www.jinglepings.com/
[20:04] <TJ-> sarnold: Yes, that is what inspired me before xmas
[20:04] <TJ-> sarnold: I knew there had to be a way to do it easily but they didn't publish any tech details
[20:05] <sarnold> TJ-: aha :)
[20:05] <sarnold> yeah it'd be fun to know a bit more about how they put it together
[20:07] <TJ-> I was thinking of doing something along the lines of the 'million dollar web-page' :D
[20:10] <sarnold> haha :D
[20:10] <sarnold> a friend put together https://ascii.town/explore.html
[20:30] <xrandr> This is probably a bad idea, but is there an easy way to have ufw allow everything EXCEPT icmp?
[20:31] <sarnold> why yes that *is* a bad idea :)
[20:32] <xrandr> sarnold: Well, I am running a game server with multiple games. Instead of adding a firewall rule for each game a customer wants to run, I figured I'd just leave it all open. I don't want ICMP attacks though
[20:32] <sarnold> xrandr: what's an ICMP attack?
[20:32] <xrandr> sarnold: ping flood, etc.
[20:33] <sarnold> xrandr: if you're under volumetric attack the right answer is to ask your ISPs to add filtering rules
[20:35] <xrandr> sarnold: Yes. that would be if they did that. As I rent the server from them, their policy states it is my job to secure the server. One of the major problems I have had in the past (especially with IRC servers) was the ping flood. So that is why I am asking how to allow everything EXCEPT icmp.
[20:35] <sdeziel> ICMP shouldn't be blocked because it breaks PMTU (among other things)
[20:35] <sdeziel> xrandr: ^
[20:35] <xrandr> sdeziel: PMTU?
[20:35] <sdeziel> xrandr: Path MTU discovery to be precise, aka how big can the packets be on a given path between your clients and the server
[20:36] <xrandr> alright
[20:36] <sdeziel> xrandr: not everyone support a MTU of 1500 so PMTU is a way to find which size is right
[20:37] <xrandr> sdeziel: ok, well my goal is to prevent a ping attack. What would you suggest then?
[20:37] <sdeziel> xrandr: if you want to drop ping, drop that specific ICMP type
[20:38] <xrandr> so ICMP ECHO then
[20:40] <sdeziel> xrandr: echo request is probably what you want to drop/reject
[20:40] <xrandr> ok.
[20:40] <xrandr> but it is still possible to allow everything else through, correct?
[20:43] <sdeziel> xrandr: if you only want to drop ICMP echo requests, I'd say that using ufw is way over kill
[20:43] <sdeziel> xrandr: I don't know/use ufw so I can't guide you with it but it would be trivial to do with iptables-persistent
[20:44] <sarnold> I don't think it's even worth bothering
[20:44] <xrandr> sdeziel: alrighty
[20:44] <sarnold> if you configure your machine to not send back ping replies, that'll annoy you when you want to debug it
[20:44] <sarnold> and people can simply send tcp floods anyway
[20:44] <sarnold> or udp floods
[20:45] <sdeziel> xrandr: sarnold has a good point. An compromise might be to use --limit to permit some ping through
[20:46] <xrandr> that could work too
[22:01] <DammitJim> I'm on Ubuntu 16
[22:02] <DammitJim> how do I disable automatic updates from happening?
[22:02] <DammitJim> there information online is so confusing
[22:02] <DammitJim> I am fine with the system telling me how many updates available there are
[22:02] <DammitJim> but I can't figure out where the system says, oh, I have to update
[22:08] <OerHeks> https://askubuntu.com/questions/953779/programmatically-disable-apt-unattended-upgrades
[22:47] <TJ-> Is there a way to acquire a replacement IPv6 address when DAD stops the requested assignment. Network is using prefix delegation and due to the gateway/router being rebooted systems ended up with duplicates but didn't try to drop the duplicate and request a fresh address ?


[23:21] <lubuntu> hello
[23:23] <kc2bez> Guest36524: do you have a support question?
[23:23] <kc2bez> guess not
[23:30] <KGIII> Hmm... It'd be interesting if the IRC client could give each a random(ish) username so that they're not have their name changed 30 seconds after opening the chat for support. LubuntuXXX, where X is a random number. I suppose someone could register all 999 numbers to be a jerk, but hopefully they'd not do that.
[23:31] <KGIII> Or just start them as GuestXXXXX in the first place.
[23:35] <guiverc> yeah I've occasionally though that too KGIII... it's more changes (patches)  to the upstream packages though every time upstream changes anything I guess
[23:36] <KGIII> Maybe if the username was left blank it'd assign a guest username? Let me check.
[23:38] <KGIII> It will not accept a blank username. There goes that idea.
[23:38] <KGIII> Maybe that can be changed programatically, I have no idea. I am not a competent programmer.
[23:38] <KGIII> 10 PRINT "HELLO WORLD!"
[23:39] <KGIII> 20 GOTO 10
[23:42]  * guiverc thinks that code will work... no syntax errors... we maybe have a new Lubuntu dev in the making :)
[23:42]  * guiverc we're off-topic here .. -devel makes more sense for irc/quassel stuff, -offtopic the rest
[23:43] <KGIII> I plan on bringing it up at the next standup. So, it'll be on topic eventually!
[23:47] <guiverc> on-topic I was thinking about this being the Support room.. (changes to IRC/quassel is devel talk)
[23:53] <KGIII> I meant the next time I bring it up it'll be on topic. That'll be at the meeting. I'll mention it then. Maybe it'll get some traction.


[02:39] <Oldposdells> HI
[02:39] <Oldposdells> I have a question. What audio controls does Ubuntu Studio have?
[03:05] <ScottL> eh, he's gone already :(
[04:10] <holstein> hehe
[04:10] <holstein> it has all of the audio controls ;p
[14:35]  * hermanr notices "General music making and studio chatter is allowed" in the topic ...
[14:36] <hermanr> ... wondering how welcome Rosegarden is, as a topic. :-)
[14:38] <hermanr> By the way, there is an IRC meeting for Cinelerra-CV today, at 16.00 UTC (that's in 1 hour and 20 minutes)
[14:38] <azm> its quite silence here. You will get faster response in #opensourcemusicians probably
[14:38] <holstein> hermanr: hey
[14:38] <holstein> we have an ubuntustudio meeting today too :)
[14:38] <holstein> in 20 minutes
[14:39] <holstein> over in #ubuntustudio-devel
[14:39] <hermanr> One hour, or open-ended?
[14:39] <holstein> hermanr: probably pretty loose
[14:39] <holstein> azm: o/
[14:39]  * hermanr needs to focus on the cinCV meeting
[14:39] <azm> hello holstein
[14:39] <azm> suddenly channe lalive :)
[14:39] <azm> channel
[15:28] <hermanr> azm: #opensourcemusicians was the right crowd, indeed! :-))
[15:29] <phed__> hei hermanr btw
[15:31] <hermanr> phed__: Hei :-)
[16:02]  * hermanr was confused about DST; the #cinelerra meeting is in one hour, not now
[16:03] <hermanr> .oO(I'd better take a nap now...)
[16:39] <AnAnt> Hello, is there some sort of setting (gconf maybe) to change the default session to Classic instead of Unity ?
[23:26] <mdennis> I'm trying to diagnose a MIDI transport issue and I'm kind of at a loss and not finding useful documentation... Install's from UbuntuStudio DVD for 10.10 (x86), I have jack running, MUSE connecting through it, transport controls seem to work, and ZynAddSubFX can receive at least the first channel fine, but I can't seem to get either FluidSynth or Timidity-daemon to do anything...
[23:28] <mdennis> I can't even find the frontends to Timidity despite them apparently being installed, and Qsynth is behaving like no input's being received at all (MUSE and FluidSynth are connected in the ALSA tab of Jack's connections window)
[23:36] <mdennis> (I did find the command-line player but it provides no sound output when run on a GM file either.)
[23:36] <mdennis> (er, command-line player for timidity)
[23:38] <holstein> mdennis: hey
[23:38] <holstein> im going to suggest a couple things
[23:38] <holstein> first, try #opensourcemusicians
[23:38] <holstein> more MIDI folk over there
[23:39] <holstein> yoshimi is the updated well-maintained fork of zynaddsubfx
[23:39] <holstein> mdennis: do you have a soundfont loaded in qsynth?
[23:40] <holstein> qsynth, like rosegarden and the other MIDI gear
[23:40] <holstein> doesnt make any sounds
[23:40] <mdennis> Yeah, I have FluidR3_GM loaded and some instruments mapped to the relevant channels
[23:41] <mdennis> (More interested in getting Timidity working given the intended purpose of the box, but qsynth is talked about more in what documentation I could find and all)
[23:42] <holstein> yeah, you'll find folks at that channel i linked
[23:42] <holstein> that use that gear
[23:42] <holstein> i dont do much MIDI
[23:42]  * mdennis nods.


[01:30] <dcg> hi all, having some issues getting multiple X servers running on maverick.
[01:32] <dcg> have 2 servers running :0 on VT7 and :1 on VT9  unfortunately I can only have one of them displaying at a time, (yes I do have a working setup for 2 monitors/keyboards/mice)  basically to view the other X server I have to hit CTRL-ALT-F7 or CTRL-ALT-F9 from the currently focused keyboard.
[01:32] <dcg> does anyone have some suggestions?
[03:07] <TariQMowafy> hello
[03:08] <TariQMowafy> hello
[03:08] <TariQMowafy> anybody here?
[05:13] <kklimonda> good morning
[05:51] <latenal> hello, I need some help. I have a built-in blueotooth device. Few days ago it start to have trouble to connect to my handsfree but was ok with my cellphone. I tried to install/uninstall blueman and bluez and after few manipulations the daemon stopped working. I can't start it any more
[05:52] <RAOF> !support
[05:52] <ubot2> The official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org and http://askubuntu.com
[05:52] <RAOF> You'll probably get more help in any of those avenues.
[05:53] <latenal> thank you
[05:58] <broder> by the way, in case there was ever any doubt, NV-CONTROL is a really crappy protocol to work with
[05:59] <broder> on the plus side, i think the daemon i'm currently writing for work that tries to automatically handle hotplug events on NVIDIA is GPL tainted, so it might get to see the light of day :)
[06:04] <RAOF> Oh!  Does NV-CONTROL actually generate hotplug events?  Cool :)
[06:05] <broder> no, but i'm polling for them :)
[06:05] <broder> generating useful events would be entirely too, well, useful for NV-CONTROL
[06:17] <TheMuso> lol
[07:35] <didrocks> good morning
[07:57] <pitti> Good morning
[08:06] <Sweetshark> didrocks, pitti: Good Morning!
[08:06] <pitti> hey Sweetshark, moin moin!
[08:07] <didrocks> Guten Morgen pitti und Sweetshark
[08:09] <glatzor> morning mvo pitti
[08:10] <pitti> hey glatzor
[08:10] <pitti> glatzor: great work on aptdaemon! looks really cool
[08:10] <glatzor> thanks pitti
[08:12] <pitti> mvo: speaking of which, do you want to sponsor this? or want me to?
[08:13] <pitti> robert_ancell: hey Robert, good evening!
[08:14]  * Sweetshark reboots
[08:14] <mvo> hey glatzor! thanks for your mail
[08:15] <mvo> pitti: I'm working on it currently, there is a test-failure left (but only on build anoyingly)
[08:15] <pitti> ah, great
[08:15]  * pitti hugs glatzor and mvo
[08:18] <pitti> robert_ancell: do you have some time to look into this webkit bug 710582?
[08:18] <ubot2> Launchpad bug 710582 in webkit "webkit crashes on amd64 architecture with SIGSEGV in WTF::OSAllocator::reserveAndCommit() was: webkit does not implement "assert" sanely" [Critical,Confirmed] https://launchpad.net/bugs/710582
[08:23] <didrocks> hey glatzor, mvo
[08:23] <glatzor> morning didrocks
[08:27] <mvo> hey didrocks
[08:30] <robert_ancell> pitti, not tonight but can tomorrow
[08:30] <pitti> robert_ancell: I was just wondering in general, depending on your current workload; if you are already overloaded, I'll look for someone else
[08:32] <robert_ancell> pitti, assign it to me
[08:33] <pitti> robert_ancell: ok, thank you
[08:33] <jasoncwarner> hey robert_ancell, I think we are good on that meeting for tonight...no worries...pitti set my mind at ease ;)
[08:34] <robert_ancell> jasoncwarner, oh, np
[08:35] <mvo> hey jasoncwarner, welcome back, isn't it terrible late in your TZ ?
[08:35] <jasoncwarner> hey mvo, not terribly, ;)
[08:35] <jasoncwarner> but for what time I normally wake up, it is getting late!
[08:35] <mvo> heh .)
[08:43] <didrocks> hey jasoncwarner
[08:44] <jasoncwarner> morning didrocks!
[08:44] <jasoncwarner> pitti tells me that you've been slacking ;)
[08:44] <jasoncwarner> says you are never doing awesome things and never completely amazing him with your work ethic and dedication ;)
[08:44] <pitti> yeah, a whole 4 hours during his sleep!!!!
[08:45] <Sweetshark> jasoncwarner: Oh, just a short question: What are your usual work hours currently? I know nothing is usual currently with all that exciting stuff going on, but I keep calculating timezones ... ;)
[08:46] <jasoncwarner> Sweetshark: I normally work San Francisco hours....
[08:46] <jasoncwarner> which was easier to tell people when the clocked worked with timezones ;)
[08:49] <didrocks> jasoncwarner: yeah, totally slacking :)
[08:49] <didrocks> I +1 pitti
[08:49] <didrocks> sorry, time for one of my 20 naps of the day :)
[08:49] <jasoncwarner> ha!
[08:49] <pitti> *chuckle*
[08:49]  * pitti hugs didrocks
[08:50]  * didrocks hugs pitti back
[08:50] <pitti> didrocks: don't forget to watch Big Bang Theory in between them!
[08:50] <Sweetshark> When I met didrocks at FOSDEM he wasnt even sleeping ...
[08:50] <didrocks> pitti: hehe, I have 3/4 episod late on the last season!
[08:50] <didrocks> you see, unity destroy my life, I even can't keep up Big Bang Theory :)
[08:50] <jasoncwarner> rock paper scissor lizard spock!
[08:51] <pitti> didrocks: ah, I already caught up all the way until 4/14
[08:51] <pitti> didrocks: I informed you thusly!
[08:51] <didrocks> pitti: excellent, I'm still at 4/11 IIRC ;)
[08:51] <pitti> man, I love that show
[08:52] <didrocks> yeah, it's so nice :)
[08:52] <didrocks> I think now that I saw that one, I even prefer it than The IT Crowd
[08:52] <didrocks> (well, maybe not the "The Internet" episod) ;)
[08:52] <Sweetshark> pitti: Dont be cruel, I got the first two seasons as DVDs from my brother for my birthday, but he insisted he would like to look them together with me. And he is currently in Ingolstadt helping making nice german cars during the week that prolongs stuff needlessly.
[08:53] <pitti> Sweetshark: argh, poor you
[08:54] <pitti> didrocks: yeah, me too; but at least I still have the 4th episode of IT crowd left to watch
[08:55] <didrocks> pitti: oh right, I hadn't started watching the last season as well!
[08:55] <Sweetshark> In my desperation I already stopped the DVD in one of the episodes we had already seen and analysed the physics on the whiteboards.
[08:56] <didrocks> Sweetshark: and so? are things correct or is it nuts?
[08:56] <Sweetshark> didrocks: correct mostly
[08:56] <didrocks> without any stop, it seemed to be correct as well, but I didn't analyse closly
[08:57] <didrocks> closely*
[08:57] <Sweetshark> at least the quantum mechanics stuff. Dunno about the string theory. Im not into esoterics ;)
[08:59] <pitti> Sweetshark: at least you can live in the peace of mind that _nobody_ knows whether it's correct :)
[09:00] <pitti> so your guess is as good as anyone elses's
[09:02] <didrocks> (small notice: so, the invisible window bug is still there, but very very rare though… The good news is that *now* we have a reproducible test case \o/)
[09:03] <pitti> at least I'm using unity again since yesterday evening, and I haven't gone nuts again yet
[09:05] <didrocks> you can trigger it in the classic session as well  ;)
[09:05] <didrocks> you won't escape compiz bugs like that!
[09:05] <didrocks> but agreed, the situation is way better
[09:06] <pitti> didrocks: not in classic+metaicy :)
[09:06] <pitti> (which is what I was using)
[09:06] <didrocks> pitti: that's cheating though :)
[09:06] <pitti> you should try metaicy, it's yummy
[09:06] <pitti> metacity works as well, though
[09:06] <didrocks> I was using metacity the past last years TBH :)
[09:06] <didrocks> (just switched for a cycle to compiz when it was the new bling bling)
[09:17] <dpm> good morning all
[09:17] <pitti> hey dpm
[09:17] <dpm> hey pitti. It seems there's been some feedback of non-working FF lucid translations in the -proposed langpacks -> https://lists.ubuntu.com/archives/ubuntu-translators/2011-February/004395.html
[09:18] <didrocks> hey dpm
[09:18] <dpm> heya didrocks :)
[09:19] <pitti> dpm: oh, thanks; I'll remove that one from -proposed right away then
[09:20] <dpm> ok, let's see if we get some more feedback
[09:20] <pitti> $ cat 10.04/whitelist.txt
[09:20] <pitti> fi
[09:20] <pitti> oc
[09:20] <dpm> hm :(
[09:20] <pitti> dpm: I'm not entirely sure what the whitelist is, but that might not be a coincidence
[09:20] <pitti> is -oc broken as well?
[09:20] <dpm> it seems po2xpi is the culprit here then?
[09:20] <dpm> not sure
[09:21] <dpm> let me see if I can install a few in my lucid pc
[09:25] <seb128> hey
[09:28] <didrocks> salut seb128
[09:29] <rodrigo_> morning
[09:31] <seb128> hey didrocks rodrigo_
[09:32] <seb128> how are you?
[09:32] <didrocks> good morning rodrigo_
[09:32] <didrocks> I'm fine, thanks, you?
[09:33] <rodrigo_> hi seb128, didrocks
[09:34] <seb128> didrocks, I'm fine as well, a bit late to start, I ran out for some errands before starting
[09:34] <didrocks> seb128: sunny days?
[09:35] <didrocks> or cloudy weather like in Lyon? :)
[09:35] <seb128> no, it's not sunny here, rather went out to get some coffee and something to eat
[09:35] <seb128> running out of breakfast stuff here ;-)
[09:35] <pitti> bonjour seb128
[09:35] <seb128> hey pitti
[09:36] <didrocks> seb128: hehe, not a nice way to start the day, right. errands were mandatory then :)
[09:36] <seb128> I got coffee and cake so that's fixed, I can work ;-)
[09:42] <seb128> didrocks, did you get comments about the compiz update?
[09:42] <seb128> pitti, do you run again unity?
[09:42] <pitti> seb128: yes, I do
[09:42] <pitti> since the update last night
[09:42] <didrocks> seb128: yeah, still some invisible window issue
[09:42] <seb128> working fine?
[09:43] <pitti> seb128: no problems so far
[09:43] <seb128> didrocks, ok, as you thought
[09:43] <didrocks> seb128: but the good news is that we have a reproducible test case now
[09:43] <seb128> didrocks, using apport? ;-)
[09:43] <didrocks> seb128: no, synaptic :-)
[09:43] <seb128> I didn't try yet here but I get it almost every time I use update-manager and the polkit daemon crashes
[09:44] <seb128> which triggers apport and let compiz in a broken state
[09:44] <didrocks> yeah, it's really a criptic path that has been reported as well :)
[09:44] <didrocks> but it "works" as triggering the bugs reliably
[09:44] <didrocks> bug*
[09:44] <didrocks> so nice :)
[09:44] <seb128> or rather than waiting for polkit to crash just hit esc on the password dialog
[09:44] <seb128> update-manager freaks out and freeze for 5 minutes and apport display a dialog and break compiz
[09:44] <didrocks> yeah, apparently, compiz just ask for paint rather than create create reparent…
[09:45] <seb128> didrocks, ok, great, it means sam can work on it now then?
[09:45] <didrocks> as it is thinking the window is already there
[09:45] <didrocks> yeah, he's already aware of that :)
[09:45] <didrocks> so, basically, 3 bugs before merging back the glib branch to trunk:
[09:46] <Sweetshark> .oO(apt-get build-dep libreoffice <= WooHa!)
[09:46] <didrocks> 1. alt / tab being slow (almost finished)
[09:46] <didrocks> 2. this invisible window
[09:46] <didrocks> 3. test the new order with the sn_* crash
[09:46] <seb128> I get the sn_ crash every second login
[09:47] <seb128> would be nice to get it fixed ;-)
[09:47] <didrocks> maybe removing my workaround with the new patch for it can be an help
[09:47] <seb128> Sweetshark, hey, what about it? hours of downloads? ;-)
[09:47] <didrocks> but there is an ABI break and such…
[09:47] <didrocks> so I prefer rather than running untested stuff that it lands to trunk + make dist as we need to do that rebase
[09:49] <Sweetshark> seb128: nah, downloads are fast here ...
[09:49]  * Sweetshark has 100MBit downstream at home ...
[09:49] <seb128> didrocks, right
[09:50] <seb128> Sweetshark, that's quite a nice internet access indeed ;-)
[09:50] <pitti> Sweetshark: wow, but you don't have a large "Uni Hamburg" plate on your front door, do you?
[09:52] <Sweetshark> pitti: nope. Than it would even be faster. Uni Hamburg also has some huge IPv4 ranges. Good that they build DESY here before the dawn of the WorldWideWeb ...
[09:58] <Sweetshark> we got fibreglas connections around here and cable TV and phone are served over that connection as a sideeffect. 100MBit/s almost never get saturated for simple downloads as some server on the way will choke. bittorrrent is the only thing that lights up stuff completely ...
[09:59] <Sweetshark> No I was wondering about all the additional packages that got installed as I already build LO without them ;)
[10:00] <Sweetshark> ... but that was without --with-system-libs ...
[10:01] <seb128> Sweetshark, right, debian and ubuntu tend to not like using lib copies
[10:01] <seb128> it means you have copies of the code to update every time you fix a bug or a security issue
[10:02] <Sweetshark> Is there a policy that packages must build single-threaded? Because LO does and well, it could be a lot faster ...
[10:03] <pitti> Sweetshark: no, the buildds use DEB_BUILD_OPTIONS=parallel=4
[10:03] <pitti> Sweetshark: most packages actually build with "debuild -j4"
[10:03] <pitti> but that also runs debian/rules in parallel
[10:03] <pitti> which the current LibO package fails on
[10:04] <pitti> Sweetshark: but if you set the above, it'll be a lot faster indeed (replace 4 with your number of cores)
[10:04] <pitti> Sweetshark: on my core i5 2.4 GHz/4 GB RAM, the last OO.o built in about 3 hours
[10:05] <Sweetshark> seb128: sure, nobody likes it. But from a dev point of view it might make sense because you dont want to recompile LO everytime some system lib got updated (as LO is linking a lot of those, that would be pretty often)
[10:06] <seb128> Sweetshark, which is another reason to use the system libraries?
[10:06] <seb128> if they are dynamically loaded you don't need to rebuild l-o when a library is updated
[10:06] <seb128> if you use a copy you need to patch l-o and rebuild it...
[10:07] <pitti> Sweetshark: yeah, it's actually considered a bug if a package includes copies of system libraries
[10:07] <pitti> if it's a security sensitive thing like poppler, zlib, or pcre, the security team haunts maintainers pretty severely (and rightly so)
[10:09] <Sweetshark> seb128: In theory. In practice, API might change, LO might depend explicitly on an outdated lib or even might only run against a patched version ...
[10:10] <Sweetshark> of course, Nothing of that should happen, but it does ;)
[10:41] <Sweetshark> Hmmm, another stupid question about the debian way of building: When I apt-get source, apt-get build-dep and then apt-get source -b so that it is build via dpkg-buildpackage, what does the unpacking of tarballs?
[10:48] <pitti> Sweetshark: apt-get source -b is pretty much overkill there
[10:49] <pitti> Sweetshark: apt-get source does the unpacking, through dpkg-source -x foo.dsc
[10:53] <Sweetshark> pitti: I just trying to get my head around all the stuff that happens "around" the "real" build by the build.pl up to a complete package.
[10:53] <pitti> Sweetshark: build.pl?
[10:54] <pitti> Sweetshark: the most low-level program you should be concerned about is dpkg-buildpackage
[10:54] <pitti> -S -> build source package, -b -> build binary pacakge
[10:54] <Sweetshark> pitti: the build script in the LO build itself. Scary stuff.
[10:54] <pitti> I think most people use the "debuild" wrapper, which calls lintian and provides some extra configurability
[10:54] <pitti> Sweetshark: ah
[10:55] <pitti> Sweetshark: the entry point to building a source package is the debian/rules Makefile
[10:55] <pitti> Sweetshark: for that I suggest to do the packaging tutorial first; trying to understand that stuff on the LibO package will be ... not easy
[10:56] <Sweetshark> So one working set of commands would be: apt-get build-deps && apt-get source && dpkg-source -x && dpkg-buildpackage, right? Or is there anything missing in the chain?
[11:00] <dpm> pitti, I've had a quick look at some of the langpacks which have already been buit: es, bn, de, pt, pt_BR (same langpack), bn. In all of them firefox translations look ok to me (i.e. no obvious breakage). I could not install any other language, as the 'language-pack-LL' packages are still on the old version (I guess they haven't been built yet), and I get a conflict when trying to install the corresponding 'language-pack-LL-base', which is already on
[11:00] <dpm> the latest version for most of the languages. So I'm not sure how the translator installed the Finnish langpack, and I'm not sure if he might have created the breakage himself
[11:00]  * Sweetshark tries (but with replacing dpg-buildpackage replaced by dpkg-source -b in the unpacked dir)
[11:00] <pitti> Sweetshark: apt-get source already unpacks the source, unless you add -d
[11:01] <pitti> Sweetshark: dpkg-source -b is not what you want; you want debuild -b or dpkg-buildpackage -b
[11:01] <pitti> Sweetshark: dpkg-source -b is a very low-level (i. e. not meant for users) interface for building a source pacakge, i. e. the diff.gz/dsc
[11:01] <pitti> dpm: hm, might be your mirror which is behind? they all built over night
[11:02] <pitti> dpm: this morning at 9 am the queue was empty
[11:03] <dpm> ah, let me see...
[11:09] <Sweetshark> pitti: I want to go 'very lowlevel' to see what happens in each step that dpkg-buildpackage would do as per http://www.debian.org/doc/maint-guide/ch-build.en.html ...
[11:10] <pitti> Sweetshark: essentially it calls "debian/rules build", then "debian/rules binary" (for binary builds)
[11:10] <pitti> for source packages, it cleans, calls dpkg-source -b, etc.
[11:10] <pitti> but it's not all that important
[11:13] <Sweetshark> I just want to get a feel where the magic happens ;)
[11:14] <pitti> Sweetshark: which package do you use for studying this?
[11:15] <Sweetshark> when I run dpkg-source -b . in the dir where I ran apt-get source, I get cannot open `./debian/changelog' for reading, which is to be expected as debian is in the subdir libreoffice-3.3.0 ...
[11:15] <Sweetshark> pitti: libreoffice ;)
[11:15] <pitti> uh
[11:15] <Laney> maybe 'hello' is a better place to start ;-)
[11:15] <pitti> Sweetshark: yeah, you need to be in the source tree for every dpkg-buildpackage operation
[11:16] <Sweetshark> when I am in libreoffice-3.3.0 (actually I tried that first), I get "no orig.tar file found"
[11:16] <pitti> yeah, hello is already nontrivial, and still uses plain debhelper
[11:17] <pitti> Sweetshark: doc says dpkg-source -b <source dir>
[11:17]  * pitti never used that himself
[11:18] <Sweetshark> which is true, there is only a libreoffice_3.3.0.orig.tar.gz in ../
[11:18] <Laney> actually the hello I just got doesn't even use debhelper at all o_o
[11:19] <pitti> indeed
[11:19] <broder> right - you want hello-debhelper :)
[11:19] <pitti> Sweetshark: right, so dpkg-source actually does need to run outside the source tree
[11:19] <Laney> so if you want low level then this might be good reading
[11:21] <Sweetshark> I just want to do the low level stuff once now, to get a feeling for it so I will not freak out should the need arise someday ...
[11:21] <seb128> rodrigo_, hey
[11:22] <seb128> rodrigo_, just read your comment, we already build tomboy without the applet enabled
[11:22] <pitti> seb128: hm, do you know what the new geoclue stuff is actually supposed to do? empathy doesn't show me the location of people anywhere
[11:22] <seb128> pitti, the indicator-datetime is supposed to show "do you want to change your tz" when travelling
[11:22] <pitti> ah
[11:22] <seb128> pitti, set your tz to an u.s one and restart it
[11:22] <seb128> it should tell you "you are in germany, do you want to set that tz"
[11:23] <seb128> pitti, we don't build empathy with geoclue, it would require bringing in libchamplain to gets the maps etc
[11:23] <pitti> $ killall indicator-datetime-service; TZ=America/Chicago /usr/lib/indicator-datetime/indicator-datetime-service
[11:23] <pitti> (process:15280): Indicator-Datetime-WARNING **: Unable to create GeoClue address: Address interface already started
[11:23] <pitti> hm, I guess it's very racy with the auto-respawn
[11:24] <seb128> pitti, it's likely you need to restart geoclue as well
[11:24] <pitti> oh, indeed
[11:24] <seb128> pitti, it's rather geoclue which picks the tz
[11:24] <pitti> -ETOOMANYDAEMONS
[11:24] <seb128> the indicator just talk to geoclue
[11:25] <pitti> hm, restarted geoclue-master, and it talked to Ubuntu GeoIP; now restarted indicator-datetime-service, but no question here
[11:25] <seb128> pitti, it should be a line in the indicator
[11:25] <seb128> not a popup
[11:25] <pitti> nope
[11:25] <seb128> how did you change your tz?
[11:26] <pitti> I have them both in the foreground now
[11:26] <pitti> seb128: running the daemons with TZ=America/Chicago
[11:26] <seb128> not sure how they get the tz or if they respect that
[11:26] <seb128> or if they just read /etc/timezone or something
[11:27] <pitti> that'd be a bug
[11:27] <pitti> but let me try changing that
[11:27]  * pitti changes it in time-admin
[11:28] <pitti> (process:15490): Indicator-Datetime-WARNING **: Unable to create GeoClue address: Address interface already started
[11:28] <pitti> I keep getting that
[11:28] <pitti> (process:15490): Indicator-Datetime-WARNING **: Unable to get Geoclue address: Geoclue master client has no usable Address providers
[11:28] <pitti> anyway, I was just curious
[11:29] <seb128> pitti, ok, check with ken or ted when they are online, I didn't play much with it
[11:29] <seb128> pitti, I know it's supposed to show a "set the tz to ..." line in the indicator when it detects you are on a different tz
[11:30] <pitti> argh, argh! I have an invisible window again
[11:31] <seb128> pitti,
 oh, heh
[11:31] <seb128>  interesting workaround for the invisible window bug
[11:31] <seb128>  hide and show the desktop
[11:31] <seb128> pitti, try that maybe ;-)
[11:31] <pitti> how?
[11:31] <seb128> if you have a gnome-panel running put the "show desktop" applet
[11:31] <pitti> I don't
[11:31] <seb128> otherwise dunno
[11:31] <seb128> smspillaz, ^
[11:31] <smspillaz> seb128: wassup ?
[11:31] <seb128> pitti, thereis probably a show desktop keybinding in compîz
[11:31] <pitti> and apparently the nasty window is on top of the unity panel, I can't even open the launche rnow
[11:31] <smspillaz> seb128: pitti: Ctrl-Alt-D
[11:32] <seb128> smspillaz, how do you hide and show desktop to workaround this bug
[11:32] <pitti> smspillaz: doesn't work
[11:32] <seb128> smspillaz, thanks
[11:32] <smspillaz> I used the thing on the gnome-panel
[11:32] <pitti> smspillaz: might only work with gnome-panel?
[11:32] <smspillaz> pitti: might have changed
[11:32] <seb128> ctrl-alt-D works there
[11:32] <smspillaz> showdesktop handling is done within the wm
[11:32] <smspillaz> pitti: ccsm -> general -> keybindings -> show desktop
[11:33] <rodrigo_> seb128, yes, found out the peditor stuff is in libgnome-cil, that's where the dep comes from
[11:33] <rodrigo_> seb128, so moving those files to gconf-cil and testing
[11:33] <pitti> smspillaz|eating: thanks, I used gnome-keybinding-properties and that worked (it was Mod4+D before)
[11:33] <pitti> found a time-admin window hiding itself
[11:34] <smspillaz|eating> ok
[11:34] <pitti> nice
[11:34] <smspillaz|eating> pitti: yeah we've got a reproducible test case now so I'm going to look into it tonight
[11:34]  * pitti calls that "sanity key"
[11:34] <seb128> rodrigo_, well I assumed it was in libgnome-cil for a reason, that's why I asked you if we could move to plain gconf#
[11:34] <seb128> rodrigo_, but if we can move it to another binary nice
[11:35] <seb128> rodrigo_, check with Laney or pkgcli guys maybe though
[11:35] <rodrigo_> seb128, yes, I guess it's there for some reason, not sure which though, so yes, testing
[11:35] <rodrigo_> Laney, ^
[11:36] <Laney> you could split the peditors assembly out into another package yeah
[11:36] <Laney> I don't know if that would save you anything on the dep chain, but it's worth a try
[11:36] <seb128> is there a way to do the equivalent of "ldd" on mono bindings?
[11:36] <seb128> i.e to see what peditor depends on
[11:36] <Laney> give us a patch in Debian and we'll take it
[11:37] <Sweetshark> In case anyone is interested: mkdir foo && cd foo && apt-get source libreoffice && dpkg-source --before-build libreoffice-3.3.0 && dpkg-source -b libreoffice-3.3.0 && make -C libreoffice-3.3.0 -f libreoffice-3.3.0/debian/rules build
[11:37] <Laney> monodis --assemblyref I think
[11:37] <seb128> Laney, thanks
[11:37] <seb128> Laney, well, it would save "Name=gnome-vfs-sharp"
[11:37] <seb128> coming from /usr/lib/cli/gnome-sharp-2.24/gnome-sharp.dll
[11:38] <Laney> is that where your problematic dep comes from?
[11:38] <seb128> doh
[11:38] <seb128> the peditor one depends on gnome-sharp
[11:38] <Laney> if peditors depends on gnome-sharp thoug...
[11:38] <Laney> yeah, :(
[11:38] <seb128> right
[11:38] <seb128> that brings the gnome-vfs stack in
[11:39] <rodrigo_> seb128, the peditor stuff is in libgnome-2.24-cil
[11:39] <rodrigo_> in the upstream source code, they are with the gconf 'basic' bindings
[11:39] <seb128> rodrigo_, yes, but it doesn't make sense to split it out since gconf-sharp-peditors.dll depends on the gnome-sharp.dll
[11:39] <seb128> rodrigo_, which depends on gnome-vfs
[11:39] <rodrigo_> doesn't seem to depend on gnome-sharp.dll
[11:39]  * rodrigo_ re-checks
[11:40] <seb128> rodrigo_, monodis --assemblyref /usr/lib/cli/gconf-sharp-peditors-2.24/gconf-sharp-peditors.dll
[11:40] <Laney> rodrigo_: try monodis --assemblyref /path/to/dll | grep Name
[11:40] <seb128>         Name=gnome-sharp
[11:40] <Laney> you can see it probably with "using Gnome;" in the sources
[11:40] <Laney> it probably follows the c lib
[11:40] <seb128> $ monodis --assemblyref /usr/lib/cli/gconf-sharp-2.0/gconf-sharp.dll | grep Name
[11:40] <seb128> 	Name=mscorlib
[11:40] <seb128> 	Name=glib-sharp
[11:41] <seb128> that one is better ;-)
[11:42] <Laney> I don't know the API at all, but maybe you can replicate it on top of gconf#
[11:43] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/ubuntu-geoip/+bug/715445
[11:43] <ubot2> Launchpad bug 715445 in ubuntu-geoip "indicator-datetime doesn’t get geoclue information from ubuntu-geoip-provider" [Undecided,New]
[11:43] <pitti> seb128: ah :)
[11:43] <seb128> pitti, you might get that bug
[11:43] <rodrigo_> right, it indeed uses some Gnome. stuff, just for the filepicker button
[11:43] <rodrigo_> I guess we can just change that to use Gtk.FileChooser
[11:44] <seb128> rodrigo_, is that exposed to the clients? i.e would that be an api, abi breakage?
[11:45] <rodrigo_> not exposed, afaics
[11:45] <seb128> rodrigo_, did you talk to upstream tomboy about that?
[11:45] <seb128> just to know what they think
[11:46] <rodrigo_> seb128, yes, but it's got nothing to do really with tomboy, tomboy just uses the PropertyEditor objects in gconf#
[11:46] <Laney> ddd
[11:46] <seb128> rodrigo_, well, it uses an api which use libgnome
[11:46] <rodrigo_> yes, but lignome usage is internal to gnome-sharp
[11:46] <seb128> rodrigo_, so they need to clean that in some way, either by moving away from propertyeditor or by changing the bindings
[11:47] <seb128> rodrigo_, right, so either we move the issue to gnome-sharp
[11:47] <rodrigo_> yes, changing the bindings is the easiest, it seems
[11:47] <seb128> or we port tomboy to not use propertyeditor
[11:47] <rodrigo_> the usage of PEditor in tomboy is huge
[11:48] <seb128> bah
[11:48] <seb128> so it means gconfpeditor should be updated to stop using libgnome
[11:48] <seb128> then the libgnome2.24-cil should be splitted
[11:48] <Laney> it would be an api break as far as i can see
[11:48] <seb128> or the gconfpeditor binding moved with gconf#
[11:49] <Laney>         void Changed (object obj, Gnome.ColorSetArgs args)
[11:49] <rodrigo_> yeah, indeed
[11:49] <seb128> k
[11:49] <seb128> tomboy really need to stop using gconfpeditor
[11:49] <seb128> to switch to gsettings or something
[11:50] <seb128> rodrigo_, just forget about it for this cycle then, porting tomboy to gconf# seems work over what it's worth
[11:50] <rodrigo_> ok, but I'll change the description of the bug
[11:50] <seb128> shame because it's the only thing keeping libgnomeui and libgnome on the default install
[11:50] <seb128> rodrigo_, can you check with upstream what are they gnome3 plans anyway?
[11:50] <seb128> they need to stop using libgnome some day
[11:50] <seb128> using gsettings or something else
[11:50] <rodrigo_> seb128, sure
[11:51] <seb128> thanks
[11:51] <Laney> the mono gi stuff is currently being hacked on
[11:51] <Laney> so we should be able to get better bindings in the near future
[11:52] <seb128> those will be really welcome
[11:52] <seb128> it sucks to be stucked with old libs because mono is so behind
[11:52] <seb128> ups
[11:53] <seb128> Laney, btw is there any plan in debian to update mono from 2.6 to 2.8?
[11:54] <seb128> Laney, or alternatively any reason why 2.6 is better?
[11:55] <Laney> we are skipping to 2.10 and it's being worked in git currently
[11:55] <Laney> most of the work was on polishing for squeeze
[11:56] <seb128> ok...
[11:56] <seb128> is 2.10 out yet? will that land in debian before natty feature freeze or not?
[11:56] <seb128> just trying to figure what we should do in natty
[11:56] <seb128> hum, lunch time
[11:56] <Laney> it's on RC2 currently, and no probably not
[11:56] <seb128> ok
[11:56] <seb128> so I guess stay on 2.6
[11:56] <seb128> thanks
[12:16] <dpm> hey didrocks, are you still having issues ssh'ing to people.canonical.com? I am having them now, but I want to confirm it's not just me before asking IS
[12:17] <didrocks> dpm: just tried, it seems to be okayish… the ssh connectin hasn't dropped for a minute…
[12:18] <dpm> ok, thanks didrocks
[12:19] <dpm> ah, it just worked for me right now as well
[12:20] <didrocks> seems that there are some underlaying network issue in any case…
[12:32] <seb128> rodrigo_, did you confirm the vino issue or just reopened the bug to track it?
[12:33] <rodrigo_> seb128, confirmed it, and found it seems to be an avahi issue
[12:33] <rodrigo_> seb128, see my last comment
[12:35] <seb128> rodrigo_, ok, emails are lagging behind, I just got the one about the bug being reopen and assigned to you
[12:35] <rodrigo_> seb128, my comment: "Following DaveHansen's comment, if you stop avahi daemon, no CPU high usage. Ditto if you restart avahi daemon again after having stopped it. So seems it's indeed an avahi problem"
[12:35] <seb128> just read the comment on launchpad
[12:35] <seb128> rodrigo_, yeah, got it now, thanks ;-)
[12:36] <rodrigo_> I'm debugging avahi-daemon now, although it seems I'll need to restart the session
[12:36] <rodrigo_> can't get it to use 100% cpu now
[12:36] <rodrigo_> well, 40% for me, rather than 100%
[12:37] <seb128> I usually get the issue by running vino-preference and checking, unchecking the checkbox to share
[12:38] <rodrigo_> seb128, yes, me too, but after restarting avahi-daemon, can't
[12:39] <dpm> pitti, chrisccoulson, ok re: the lucid-proposed language packs, it seems that FF translation breakage only affects the whitelisted languages in po2xpi (that's 'fi' and 'oc').  I've reported it on bug 715733
[12:39] <ubot2> Launchpad bug 715733 in po2xpi "XPI files are not correctly built for whitelisted templates" [Undecided,New] https://launchpad.net/bugs/715733
[12:47] <seb128> chrisccoulson, current firefox failed to build on armel and powerpc, fix it! ;-)
[12:47] <seb128> didrocks, current unity failed to build, fix it ;-)
[12:48] <didrocks> seb128: trunk or the package?
[12:48] <seb128> if you wonder about those it's thanks to robert_ancell who made build failures be listed on http://people.canonical.com/~platform/desktop/versions.html
[12:48] <seb128> didrocks, 3.4.0-0ubuntu2
[12:48] <seb128> didrocks, though a retry now that glew is fixed might work?
[12:48] <seb128> let me try that
[12:49] <chrisccoulson> seb128 - one step ahead of you already ;) http://bazaar.launchpad.net/~mozillateam/firefox/firefox-4.0.head/revision/759
[12:49] <didrocks> seb128: yeah, it was due to glew
[12:49] <didrocks> seb128: I didn't retried on purpose, thinking that for such a small fix in alpha2, it will prevent people pushing their bugs with apport
[12:49] <didrocks> now, I think it's fine
[12:49] <seb128> didrocks, ok, let's try then
[12:49] <seb128> chrisccoulson, ok, you are fine for this time but we are watching you :p
[12:49] <didrocks> (taking the predicate that apport is basing the version on the published binary )
[12:50] <chrisccoulson> heh :)
[12:50] <didrocks> hope that the second time I'm fixing the same issue in glew will be the latest
[12:50] <seb128> didrocks, there is a new glew in debian btw
[12:50] <seb128> should we sync? ;-)
[12:51] <didrocks> seb128: just look if the .pc file requires glu :)
[12:51] <didrocks> then, for driver issue, I'm not there anymore \o/
[12:51] <didrocks> maybe better to wait on an unity release to blame dx :)
[12:52] <didrocks> like "I updated glew and unity and unity doesn't run!" :)
[12:52] <seb128> lol
[12:52] <seb128> yeah ;-)
[12:52] <didrocks> (I can also update compiz too to add to the confusion ;))
[13:02] <Sweetshark> \o/ the libreoffice package finished to build ...
[13:02] <Sweetshark> ... kinda ...
[13:03] <Sweetshark> ... well, it chrashes in smoketest, but thats what smoketests are for, right?
[13:17] <pitti> dpm: thanks; so let me remove them from the whitelist and rebuild these two
[13:18] <dpm> pitti, ok. Could you please also remove the 'ca' language packs from lucid-proposed? They are failing as well (Firefox in English, no FF translations in the langpack), but probably for some other reason
[13:23] <pitti> dpm: ah, oc and fi's mozilla.tar.gz are unpacked, while the others have a XX.jar archive
[13:29] <mvo> didrocks: what is the best way to test oneconf when you only have one machine?
[13:29] <mvo> didrocks: is there something like FAKE_MACHINE=1 ;) ?
[13:30] <pitti> VMs?
[13:30] <didrocks> mvo: I think I wanted to implement that, not sure I've done, let me check :)
[13:31] <didrocks>         # faking this id for testing purpose
[13:31] <didrocks>         #self.hostid = 'BBBBBB'
[13:31] <didrocks>         #self.hostname = "foomachine"
[13:31] <didrocks> in oneconf/hosts.py
[13:31] <didrocks> mvo: ^
[13:31] <didrocks> just uncomment to override real values :)
[13:31] <didrocks> then oneconf-query --update to get a first set
[13:32] <mvo> cool, thanks didrocks
[13:41] <cyphermox> hey didrocks
[13:41] <mterry> seb128, still able to crash reliably?  I have a test package for you to try
[13:42] <seb128> mterry, hey, just tried, first try, first crash
[13:42] <seb128> so I guess it's a "yes" ;-)
[13:42] <mterry> seb128, https://launchpad.net/~mterry/+archive/ppa
[13:42] <didrocks> hey cyphermox
[13:43] <cyphermox> didrocks, about my issues with building unity ;) what I was referring to was specifically using  "bzr bd" to locally build a deb for hacking. I'm aware it's no good for making sure that it builds cleanly, but it's fewer steps for hacking and testing than bzr bd -S && pbuilder, for example
[13:43] <seb128> mterry, do you have a vcs for it?
[13:43] <mterry> seb128, it's got a new version of libdbusmenu with a patch that avoids freeing a particular object.  It quieted a lot of warnings about trying to disconnect signals from invalid objects for me
[13:43] <seb128> mterry, don't bother I will grab the debdiff
[13:43] <mterry> seb128, not yet, but will have one in a sec
[13:43] <didrocks> cyphermox: right, but you have a FTBFS, right?
[13:43] <mterry> seb128, ok
[13:43] <didrocks> cyphermox: I think it's related to your branch
[13:43] <seb128> mterry, I just want to build locally so I still have the dbgsym for it
[13:43] <didrocks> cyphermox: or you can, for hacking installing unity
[13:44] <didrocks> cyphermox: then, with next release, unity --distro to remove all the cruft
[13:44] <seb128> we need soyuz dbgsym support
[13:44] <cyphermox> didrocks, it fails if I take lp:~ubuntu-desktop/unity/ubuntu ;)
[13:44] <seb128> didrocks, is anybody else than you is able to build unity?
[13:44] <pitti> dpm: I uploaded (hopefully) fixed -oc and -fi langpacks to lucid-proposed
[13:44] <seb128> didrocks, you are sure you don't have a special compiz environment set?
[13:44] <didrocks> seb128: you were, I didn't change the packaging though
[13:44] <seb128> didrocks, not I'm not
[13:44] <didrocks> nothing in my env
[13:45] <seb128> it try to install to debian/$curdir/$destdir
[13:45] <didrocks> seb128: like, it's not building for you?
[13:45] <cyphermox> didrocks, the issue is really that somehow, unless I set COMPIZ_DESTDIR, stuff gets installed in an invalid path
[13:45] <seb128> remember?
[13:45] <didrocks> cyphermox: COMPIZ_DESTDIR shouldn't be used
[13:45] <dpm> pitti, ah, cool. Did you read the message about the 'ca' ones above? ^ I don't know what's going on there, so for now I think it might be best just to remove it from -proposed
[13:45] <didrocks> cyphermox: it's breaking COMPIZ and other wrapper
[13:45] <didrocks> cyphermox: we will remove it as told
[13:45] <cyphermox> didrocks, I realize it might not be a good idea, just saying it "works" for now
[13:45] <pitti> dpm: yes, I removed it
[13:45] <didrocks> seb128: and there was no issue in a pbuilder, right?
[13:45] <seb128> didrocks, we did chat a bit about that a few weeks back
[13:46] <dpm> pitti, ok, thanks
[13:46] <pitti> dpm: I responsed, but apparently you got hit by DSL reconnect or so?
[13:46] <seb128> didrocks, didn't try pbuilder but it builds on the buildds
[13:46] <didrocks> seb128: yeah, I remember now, I would say that you have something in your env then :)
[13:46] <seb128> didrocks, ok, I though you were discussing similar issues
[13:46] <didrocks> for the same reason I can't build nux here, but ona pbuilder it works
[13:46] <seb128> I will go back in my corner
[13:46] <dpm> pitti, yeah, sorry, I didn't get the response
[13:47] <didrocks> cyphermox: setting COMPIZ_DESTDIR is a workaround that is bad. The thing is to find what causes that to you
[13:47] <didrocks> I build unity in another box to check as well
[13:47] <didrocks> (a clean install)
[13:47] <didrocks> it's working as well
[13:47] <cyphermox> didrocks, there is nothing I can think of in env that would cause this -- I'm trying another box now
[13:47] <didrocks> cyphermox: yeah, please, keep me posted
[13:47] <cyphermox> didrocks, I'll try on a live session jsut for you ;)
[13:48] <seb128> didrocks, it's weird, this box has for sure nothing not coming from the distro
[13:48] <ari-tczew> is there anyone familiar with gnutls26 ?
[13:48] <ari-tczew> I'm going to upgrade this package and looking for concerns, if so.
[13:48] <didrocks> seb128: yeah, there should be something, if someone with a box providing this issue wants to investigate
[13:48] <didrocks> but not setting COMPIZ_DESTDIR :)
[13:49] <seb128> it's a weird one
[13:49] <cyphermox> didrocks, I'm getting a usb key ready, then I'll post full bzr bd logs from a clean copy of lp:~ubuntu-desktop/unity/ubuntu
[13:49] <seb128> seems cmake related
[13:49] <didrocks> seb128: yeah, as my nux and doxygen not building :/
[13:49] <seb128> but I don't know enough about cmake to debug it
[13:49] <didrocks> cyphermox: excellet
[13:50] <didrocks> seb128: all the compiz cmake should be rewritten, honestly…
[13:50] <seb128> ari-tczew, no one here
[13:50] <cyphermox> seb128, it is, somehow it's detecting compiz's install path wrong, but I'm convinced it's not env
[13:50] <didrocks> I spent enough time to just make it works aleady
[13:50] <didrocks> already*
[13:56] <Amaranth> didrocks: Hey, I like the compiz build system :)
[13:56] <Amaranth> The way plugin building is setup mainly
[13:56] <didrocks> Amaranth: well, it's broken…
[13:56] <didrocks> needs a good refresh and refactoring
[13:57] <Amaranth> You can pull a single plugin out and build it standalone but core know how to handle them all as well with the same CMakeLists.txt
[13:57] <didrocks> yeah, this part is good :)
[13:57] <didrocks> (and we use it)
[13:57] <Amaranth> although some of it ended up being the usual build system hacks on top of hacks
[14:07]  * bcurtiswx waves to room
[14:12] <seb128> hey bcurtiswx
[14:12] <seb128> mterry, ok, seems to fix it, I tried 6 times without issues
[14:12] <seb128> mterry, it crashed every second time in average before
[14:13] <seb128> mterry, I will keep playing a bit with it but seems to work
[14:13] <mterry> seb128, sweet.  Now I have to figure out how to make a real patch vs that quick fix
[14:13] <seb128> bcurtiswx, the m-c bug you emailed me about, not sure it's really a bug...
[14:14] <seb128> mterry, do you know what is wrong or do you need a valgrind log pointing it?
[14:14] <seb128> mterry, I guess valgrind would show the issue
[14:14] <bcurtiswx> seb128, OK, thanks for looking at it :)
[14:14] <seb128> kklimonda, hi.
[14:14] <mterry> seb128, no, I know the issue...
[14:14] <seb128> mterry, ok, great, let me know if you need testing for the proper fix later on then
[14:14] <mterry> seb128, when the app's menu items are finalized, they try to disconnect from the accel group that the dbusmenu client is holding
[14:15] <mterry> seb128, I just haven't been able to find the appropriate point at which to let go of the accel group yet
[14:15] <seb128> ok
[14:15] <mterry> seb128, I shouldn't need further testing.  I see warnings when I hit the bug, it just doesn't crash like it does for you.  So as long as I can make those warnings go away, I'm good
[14:16] <seb128> mterry, ok, excellent
[14:16] <kklimonda> seb128: hey
[14:16] <seb128> kklimonda, how are you?
[14:16] <didrocks> cyphermox: did it build?
[14:17] <cyphermox> didrocks, didn't get to it yet, my iso from yesterday would oops.
[14:17] <kklimonda> seb128: a bit tired, just got back from a long walk and I'm trying to  make a fire in the fireplace ;)
[14:18] <seb128> heh, some exercice!
[14:18] <seb128> kklimonda, bug #715046, do you want to work on it?
[14:18] <ubot2> Launchpad bug 715046 in transmission "[Natty] Update Transmission to version 2.21" [Undecided,New] https://launchpad.net/bugs/715046
[14:18] <seb128> kklimonda, if so can you tag it desktop-upgrade and assign it to you?
[14:19] <kklimonda> seb128: I will work on it, but it may not be possible to update it in natty.
[14:19] <seb128> kklimonda, why?
[14:19] <seb128> kklimonda, well in any case just comment on the bug if it's not
[14:20] <kklimonda> upstream has decided to use the new libevent, which isn't completely API comptaible with the old one, and I can't couldn't fix all packages that depend on the old libevent so far.
[14:21] <seb128> kklimonda, can we use the new one with the commit requiring the new libevent reverted?
[14:21] <kklimonda> whoa, nothing like a 4 second lag to make what your write sound like a complely blabbering ;)
[14:22] <kklimonda> seb128: I don't think it's worth an effort (the rewrite has been one of the most important things in 2.20) but I'll take a look when I'm back, and ask upstream to reconsider bundling libevent2 in their source, like they did before with libevent1. We could also consider doing it ourselves.
[14:23] <seb128> kklimonda, well in any case if you tag and assign the bug that will avoid work duplication
[14:23] <seb128> so maybe just drop a comment on the bug saying what you wrote there?
[14:23] <seb128> kklimonda, thanks
[14:24] <kklimonda> yes, I'll coment on the bug in a minute.
[14:24] <kklimonda> at least assign it to myself, I'd like to ask T dev about rebundling libevent2 before I I do any more commenting :)
[14:32] <cassidy> hey guys. Any plan to ship glib-networking? You need it to be able to use proxies in Telepathy
[14:37] <didrocks> kiwinote_: hey, are you around?
[14:37] <kiwinote_> didrocks: yep
[14:38] <didrocks> kiwinote_: I was wondering if you can shed some light on the -2 magic :)
[14:38] <lamalex_> bryceh, is there any eta on nvidia drivers?
[14:38] <didrocks> kiwinote_: in the ref count, when there is a direct match to the serach
[14:38] <kiwinote_> didrocks: um yeah, that's a bit quirky
[14:39] <kiwinote_> didrocks: I aren't quite sure, but I think the query consists of different parts, and on each iteration the nr_pkgs, nr_apps counters aren't reset
[14:40] <kiwinote_> didrocks: I made that change because it would seem to give correct results now, if it disadvantages any oneconf stuff, just let me know
[14:40] <didrocks> kiwinote_: no, I'm fixing other stuff for oneconf, but the match seems correct now
[14:41] <didrocks> kiwinote_: so, I was just unfortunate that pkgs - apps was exactly the right count. I was assuming pkgs was the total, not only technical items :)
[14:41] <didrocks> I was quite curious of the fix though
[14:41] <kiwinote_> didrocks: yeah - in maverick the nr_pkgs was the total of all pkgs and apps, but that's changed now
[14:42] <didrocks> kiwinote_: right ;) well, I'm adapting to it, but the "look at the total result if there is no app found" is giving me some headaches :)
[14:53] <seb128> cassidy, is that in debian? we could just sync it if that's there
[14:53] <cassidy> it is
[14:53] <cassidy> I'm trying to open a lp bug about that since 10 minutes..
[14:53] <cassidy> but I'm always redirected to https://help.ubuntu.com/community/ReportingBugs
[14:55] <chrisccoulson> does anybody actually use thunderbird? i've had no bugs about the menus so far. not sure if that's good or bad ;)
[14:57] <kenvandine> chrisccoulson, hehe... there are always bugs :)
[14:57] <seb128> cassidy, right, we turn off bug reporting for non bugsquad by default
[14:57] <cassidy> didrocks, rahh I could have spend my day on this :p
[14:57] <seb128> cassidy, see the ?no-redirect url in the wiki
[14:57] <cassidy> I tried, didn't work
[14:58] <didrocks> cassidy: I know that, hence the ?no-redirect pointer I gave you
[14:58] <seb128> cassidy,     http://bugs.launchpad.net/ubuntu/+filebug?no-redirect
[14:58] <seb128> doesn't work?
[14:58] <cassidy> it does !
[14:58]  * cassidy blames didrocks
[14:58] <didrocks> why?
 c'est le ?no-redirec la magie
[14:58] <seb128> lol
[14:58] <seb128> with a "t"
[14:59] <seb128> cassidy, subscribe ubuntu-sponsors to the request while you are at it
[14:59] <cassidy> isn't that a bit too complex to just report a bug ? :\
[14:59] <seb128> cassidy, well usually you use "report a bug" in the menus
[14:59] <seb128> or ubuntu-bug
[14:59] <seb128> which collect infos etc for you
[15:00] <didrocks> cassidy: I told you it's written on https://help.ubuntu.com/community/ReportingBugs :p
[15:00] <seb128> cassidy, the goal is to discourage opening bug without apport since those lack infos
[15:00] <cassidy> yeah but ubuntu-bug doesn't work for the ubuntu component
[15:00] <didrocks> cassidy: ubuntu-bug without anything
[15:01] <cassidy> yeah didn't work, there is "I want to report on Ubuntu"
[15:01] <cassidy> it asks if that's a security, X issue, etc
[15:01] <seb128> hum indeed
[15:01] <seb128> well those are sort of a corner case
[15:01] <seb128> but seems an apport bug as well
[15:02] <seb128> you can probably open a bug on apport about it
[15:02] <seb128> seems it should be working
[15:02] <cassidy> seb128, didrocks: bigon: https://bugs.launchpad.net/ubuntu/+bug/715821
[15:02] <ubot2> Launchpad bug 715821 in ubuntu "Sync glib-networking from Debian" [Undecided,New]
[15:02] <didrocks> cassidy: thanks
[15:21] <bratsche> didrocks around?
[15:21] <didrocks> bratsche: yes?
[15:21] <seb128> hey bratsche, how are you?
[15:22] <bratsche> didrocks: I was told I should ping you and let you know I'm trying to get libgrip into universe.  I submitted a request here: https://bugs.launchpad.net/ubuntu/+bug/715830
[15:22] <ubot2> Launchpad bug 715830 in ubuntu "New Source Package: libgrip" [Undecided,New]
[15:22] <bratsche> Hi seb128, I'm okay.  How are you?
[15:22] <seb128> bratsche, I'm fine thanks
[15:22] <didrocks> bratsche: ok, I can check the package and look at it, thanks :)
[15:22] <bratsche> didrocks: Thanks!
[15:22] <didrocks> bratsche: not exactly right now, but later today or tomorrow
[15:23] <bratsche> Sure, no worries.
[15:23] <didrocks> yw ;)
[15:36] <rodrigo_> in which branches are the maverick packages?
[15:39] <dobey> rodrigo_: lp:ubuntu/maverick/$sourcpkgname
[15:39] <dobey> rodrigo_: or did you mean something else?
[15:40] <rodrigo_> dobey, that's what I mean, but the gtk package is not there
[15:40] <seb128> rodrigo_, we don't keep stable vcs for most of the desktop things
[15:40] <seb128> we don't work enough on stable versions to do that
[15:41] <rodrigo_> right, but I thought they were pushed to maverick branches automatically
[15:41] <seb128> rodrigo_, so I guess you need to checkout the revision before we started worked on natty or check the sru version control
[15:41]  * Sweetshark just got work: http://cgit.freedesktop.org/libreoffice/build/tag/?id=libreoffice-<IP_ADDRESS>
[15:41] <seb128> rodrigo_, well the autoimport will work, what dobey said
[15:41] <dobey> rodrigo_: it looks like it is there to me
[15:41] <dobey> rodrigo_: https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/gtk+2.0/maverick
[15:41] <rodrigo_> ah, it's gtk+2.0
[15:42] <dobey> :)
[15:43] <Sarvatt> MacSlow: any chance you could merge https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/654921 somtime? been blocking a pixman update on that getting fixed since it will look ugly
[15:43] <ubot2> Launchpad bug 654921 in notify-osd "Black border in the notifications when effects are turned off" [Undecided,Confirmed]
[15:44] <jcastro> chrisccoulson: when in the cycle do you plan on landing appmenu for firefox?
[15:45] <MacSlow> Sarvatt, on the weekend I will address notify-osd... right now there's still unity-features on my plate that need to land before the weekend
[15:46] <Sarvatt> sounds good, thanks for taking a look at it! pixman wasn't building with our GCC for a few months anyway so no rush, just would like to update it before natty release because it has quite a few speedups for the people using ARM systems
[16:00] <dpm> pitti, ok, it seems that the problem might not be with po2xpi, but with the exported files from LP: bug 715854
[16:00] <ubot2> Launchpad bug 715854 in launchpad "Exported Firefox translations contain wrong references to languages other than the current" [Undecided,New] https://launchpad.net/bugs/715854
[16:04] <seb128> kenvandine, mterry: it's getting hard finding appmenu issues!
[16:04] <mterry> seb128, yay
[16:04] <seb128> I've been triaging the bugs and playing it there, only find really minor issues
[16:05] <seb128> mterry, seems there is one issue with icons, interested by working on it?
[16:06] <mterry> seb128, sure
[16:06] <seb128> mterry, ok, I will open a bug and assign it to you
[16:06] <seb128> mterry, nautilus "go" menu has no icons for the standard locations
[16:06] <seb128> computer, trash, etc
[16:06] <seb128> u1 in the file menu also has an icon where it doesn't in the normal menu
[16:07] <seb128> mterry, I've set APPMENU_DISPLAY_BOTH=1 in my session to test
[16:07] <seb128> comparing both menus
[16:08] <mterry> seb128, weird, cool.  assign me up
[16:11] <seb128> mterry, bug #715864
[16:11] <ubot2> Launchpad bug 715864 in indicator-appmenu "icons not always displayed as they should" [Undecided,New] https://launchpad.net/bugs/715864
[16:11] <cyphermox> didrocks, I can't reproduce it on a live session -- seems like somehow once my environment is all set for building packages, there's a difference from an install of just bzr, bzr-builddeb and unity build-deps
[16:11] <didrocks> cyphermox: right, if you see something, do not hesitate to ping me :)
[16:11] <cyphermox> didrocks, I did see something
[16:12] <didrocks> (I'm using bzr bd as well)
[16:12] <didrocks> cyphermox: oh? a fix?
[16:12] <cyphermox> looks like changing COMPIZ_PLUGIN_INSTALL_TYPE to compiz from package will get good results, but I guess that might break something else
[16:13] <cyphermox> also didn't try that on buildds or pbuilder yet :/
[16:13] <rodrigo_> oh, accountsservice from the gnome3 ppa is now in universe?
[16:13] <seb128> rodrigo_, right, got synced from debian
[16:13] <rodrigo_> cool
[16:13] <cyphermox> didrocks, seems like something is setting both DESTDIR and COMPIZ_DESTDIR, which is why the paths are doubled there when the plugin gets installed (in the bug I filed)
[16:13] <didrocks> cyphermox: wait? I didn't set it to package?
[16:13] <cyphermox> didrocks, no, you did
[16:14] <didrocks> cyphermox: yeah, hence my "COMPIZ_DESTDIR is broken"
[16:14] <didrocks> package is what should be set
[16:14] <didrocks> to get the right debug options triggeed
[16:14] <didrocks> triggered*
[16:14] <didrocks> and so generating -dbgsym
[16:14] <cyphermox> right
[16:14] <cyphermox> but nah, it still didn't work anyway
[16:16] <cyphermox> didrocks, the issue is that here DESTDIR is already set, but in CompizPlugin.cmake COMPIZ_DESTDIR also gets set to DESTDIR -- in the same file, the plugin is set to be installed to ${COMPIZ_DESTDIR}/somethingsomething
[16:16] <didrocks> cyphermox: I know, but CompizPlugin.cmake set COMPIZ_DESTDIR only in Compiz mode normally
[16:16] <didrocks> not package one
[16:17] <cyphermox> hm
[16:19] <seb128> ok...
[16:19] <seb128> mterry, do you know where is the code to display the "close" item for dialogs which don't have a menu to display?
[16:19] <mterry> seb128, I believe in indicator-appmenu
[16:20] <seb128> mterry, ok, can you confirm the "close" entry is inactive on i.e vino-preference
[16:20] <mterry> seb128, works for me
[16:20] <seb128> hum, k
[16:22] <seb128> mterry, it seems random there but is the entry is unactive for quite some capplets there
[16:23] <seb128> does it work for others?
[16:23] <seb128> didrocks, pitti, rodrigo_: ^
[16:24] <desrt> mterry: 0.7.2 makes you happy?
[16:24] <rodrigo_> seb128, hmm, 2.32 capplets you mean?
[16:25] <seb128> rodrigo_, yes, well dialogs which don't have a menu, gnome-mouse-properties, vino-properties, alacarte, etc
[16:26] <mterry> desrt, except for https://bugzilla.gnome.org/show_bug.cgi?id=640683 yes
[16:26] <ubot2> Gnome bug 640683 in gsettings backend "Mutex deadlock on unsubscribe" [Normal,Unconfirmed]
[16:26] <rodrigo_> seb128, I have gcc 3.0 here, but for vino-preferences, it's not inactive
[16:26] <mterry> desrt, but I have worked around that for my case, and I think it's a hard-to-reproduce one
[16:26] <seb128> rodrigo_, ok, thank you
[16:26] <desrt> that's probably gdbus, right?
[16:26] <seb128> rodrigo_, small issue but I will watch for it
[16:26] <rodrigo_> seb128, you're welcome :)
[16:27]  * desrt catches up on the bug
[16:27] <mterry> desrt, either that or how dconf uses it
[16:27] <desrt> mterry: we have another bug open about 'use of gdbus' too :)
[16:30] <desrt> But notably, these widgets don't make an attempt to avoid setting a value if
[16:30] <desrt> that same value is in GSettings already.
[16:30] <desrt> mterry; :(
[16:31] <desrt> does that include when the initial value of the widget is set (ie: when starting up the app?)
[16:31] <desrt> if so, it's **very** broken
[16:32] <pitti> hey desrt, how are you?
[16:32] <desrt> pretty good
[16:32] <desrt> got a fun project this week :)
[16:32] <desrt> so i'm happy :p
[16:32] <pitti> desrt: FTR, my pygobject patch for gsettings landed :)
[16:32] <pitti> desrt: oh, what are you doing?
[16:32] <desrt> what're you working on?
[16:32] <desrt> NICE
[16:33] <desrt> the settings['key'] = (1,2,3) thing?
[16:33] <pitti> desrt: the "dict-like settings object", yes
[16:33] <desrt> did you do the automatic type hinting for the GVariant construction?
[16:33] <pitti> desrt: we are currently discussing how/when to release
[16:33] <pitti> desrt: yes, with the get_range() thing; although only with some limited support
[16:33] <desrt> what limits?
[16:34] <pitti> desrt: I only support the "type" range
[16:34] <desrt> btw: you can use the information from get_range() to ensure you never make a call that issues a g_critical() or aborts
[16:34] <desrt> ah.  i see :)
[16:34] <pitti> desrt: I haven't had time yet to implement the others (range/flags), they just throw a NotImplementedError for now
[16:34] <pitti> I think that's ok given that code which uses that is mostly 'static'
[16:34] <desrt> would be really nice if you could throw a range exception for the others
[16:35] <desrt> i guess you already throw a type exception if gvariant conversion fails?
[16:35] <pitti> desrt: once they are implemented? yes, shoudl be a ValueError then
[16:35] <pitti> desrt: yes
[16:35] <desrt> (which should automatically ensure that you always have the right type...)
[16:35] <desrt> that's really slick :)
[16:35] <desrt> brings us somewhere close to the QML API now
[16:35] <pitti> desrt: yeah, I noticed that the current gvariant implementation is very sensitive -- one false step and BANG! you program crashes
[16:36] <desrt> except that python has no convention for monitoring property values for changes, unfortunately
[16:36] <pitti> desrt: that's why I need to do rather expensive "does this key exist" tests before calling set_value() etc.
[16:36] <desrt> pitti: i went through a phase a year or so ago about "WTF is with all of these g_critical() errors in my xsession-errors"?
[16:36] <desrt> which motivated me to turn all of my g_criticals into asserts :)
[16:37] <Amaranth> Or get people to run with GDEBUG again
[16:37] <Amaranth> critical-errors or whatever
[16:38] <desrt> the best suggestion i heard is to sleep(10) on each g_critical :)
[16:38]  * desrt . o O ( wonder how long it takes for you guys to vendor-patch that one out )
[16:39] <mterry> desrt, right, my app didn't have any smarts to avoid the changed-set cycle on startup.   I would argue that using the api like that shouldn't cause a bug, but it was inefficient
[16:39] <desrt> anyway... it's vaguely on my list of things to do to go through and turn a lot of those asserts into return_if_fail()s
[16:39] <mterry> desrt, is there a reason that dconf doesn't guard against that for apps?
[16:40] <desrt> mterry: it's sometimes difficult for dconf to know what is already in the database
[16:40] <desrt> since some changes might be in-flight
[16:41] <desrt> it's not really a problem of what ends up in the database at the end of it all because that's inherently a simple (non-buggy) race
[16:41] <desrt> but it's an issue of ensuring that the state of the widget is consistent with what the final value ends up being
[16:41] <desrt> and it's not always possible to ensure that we'll always see a change signal after the skipped set request
[16:42] <desrt> last time i looked at it i was unable to convince myself that it would be 'safe' in all cases
[16:44] <desrt> we also need to carefully make the distinction about the meaning of writing a setting which is equal to the value of the setting in the systems-wide default database
[16:44] <desrt> since probably we *do* want to write those even still
[16:44] <desrt> the rule for app authors is quite simple, though: only do GSettings writes in response to explicit user action
[16:45] <ogra> didrocks, tickle
[16:45]  * desrt should document that
[16:46] <didrocks> ogra: hey
[16:46] <ogra> didrocks, the unity-2d team asked for two more patches to be included in metacity
[16:47] <ogra> https://code.launchpad.net/~unity-2d-team/unity-2d/metacity (commits 100 to 102)
[16:47] <didrocks> ogra: is there an ABI break?
[16:47] <ogra> i would like to get a signoff from the desktop team
[16:47] <ogra> hmm, not sure, it adds new functions
[16:47] <ogra> but doesnt modify existing ones as far as i can see
[16:48] <didrocks> debian/patches/17-workspace-switcher-cycle.patch
[16:48] <didrocks> -> we don't have that behavior in compiz
[16:48] <didrocks> it seems wrong
[16:48] <ogra> weird, wha does bfiller think we do then
[16:48] <ogra> *why
[16:49] <bfiller> didrocks: compiz desktop cube has this behavior will allow you to rotate from last side of cube to first side
[16:49] <ogra> ah, here he is
[16:49] <didrocks> bfiller: right, but we don't use cube by default
[16:49] <didrocks> bfiller: we have staticswitcher, where we don't use the behavior on purpose
[16:50] <didrocks> that*
[16:50] <didrocks> ogra: /apps/metacity/general/capture_before_unmap change seems fine if you can confirm it doesn't slow down on minimize
[16:50] <ogra> i will test it tomorrow
[16:50] <ogra> thanks
[16:50] <bfiller> didrocks: what if I made it configurable via gconf whould it be acceptable?
[16:50] <didrocks> bfiller: sure, but the default should be off
[16:51] <bfiller> didrocks: sounds good, I will rework it then
[16:51] <ogra> didrocks, apart from that change it is ok to go in ?
[16:51] <didrocks> bfiller: propose it upstream as well btw
[16:51] <didrocks> ogra: yeah, after the test :)
[16:51] <ogra> i.e. i dont need to bother you again and just upload after testing
[16:51] <ogra> right :)
[16:52] <ogra> great, thanks
[16:52] <bfiller> didrocks: ok
[16:52] <didrocks> yw
[16:57] <desrt> mterry: i just committed a docs patch that makes your code officially buggy :)
[16:57] <desrt> mterry: of course, i'll still keep the bug open and investigate the root issue, though
[16:58] <desrt> since it's quite likely that this issue could pop up in legitimate cases too
[16:58] <mterry> desrt, dammit  :)
[16:59] <desrt> mterry: if you have some time to kill, a small test case would go a long way :)
[17:00] <desrt> uhhhh
[17:00] <desrt> child_watch_helper_thread
[17:01] <desrt> SIGCHLD implicated in this bug?  we have an open bug about a race here (that's exceptionally difficult to solve)
[17:01] <desrt> the bug only happens in the single-threaded case of GMainLoop but what matters is how many threads GMainLoop saw by the time the child was spawned...
[17:02]  * desrt tries to find that bug
[17:02] <bryceh> lamalex_, there is not a public eta on the nvidia drivers, no
[17:03] <lamalex_> bryceh, yah- i got the memo
[17:03] <lamalex_> im really pissed at myself for just running a dist upgrade and not looking at it
[17:05] <bryceh> lamalex_, sorry to hear; we did try to give plenty of heads up, mentioned it in the release notes, etc.
[17:05] <desrt> mterry: here is the bug for reference: https://bugzilla.gnome.org/show_bug.cgi?id=398418 .  not sure it's related though
[17:05] <ubot2> Gnome bug 398418 in mainloop "GChildWatch race condition?" [Major,New]
[17:05] <lamalex_> bryceh, yah i know it was completely my fault
[17:05] <lamalex_> i have been careful about not updating, but this morning i just f'ed up
[17:06] <bryceh> lamalex_, for future reference, in EVERY release nvidia and fglrx ALWAYS break at some point, so if you want to track the development version just be prepared for being proprietary-driverless for about a month
[17:06] <bryceh> (longer in fglrx's case)
[17:09] <mterry> desrt, seems different, since later comments say only present if you don't link against gobject
[17:10] <desrt> mterry: that's because we g_thread_init() from g_object_init() these days
[17:10] <desrt> and a thread-safe mainloop is immune to this bug
[17:11] <desrt> it looks like you have two separate bugs here, though
[17:11] <desrt> one of them is a deadlock on a GDBusConnection lock (with no all-threads backtrace to discover the true issue)
[17:11] <desrt> the other two are GMainLoop deadlocks
[17:13] <desrt> hmm.  this really really looks like heap corruption
[17:15] <desrt> could just as easily be dconf's fault, of course
[17:15] <desrt> (for corrupting the heap)
[17:17] <mterry> desrt, well, it's just that it goes away with a really small patch to avoid spamming dconf
[17:17] <desrt> mterry: there's a rather insideous bug hiding here
[17:18] <desrt> you've exposed it.  i'm rather happy that you did.  please don't hide it again :p
[17:18] <mterry> desrt, it's simple enough to turn off my patch in my code and test dconf in future
[17:18] <desrt> true.  but that will never happen :)
[17:19] <desrt> have you tried valgrinding?
[17:20] <mterry> desrt, well, I can easily test patches is all I'm saying.  But the combination of difficulty of creating a test case and since I worked around it...
[17:20] <mterry> desrt, yeah
[17:20] <mterry> desrt, nothing notable, except for a memory leak due to bad vala bindings  :)
[17:21] <desrt> valgrind is particularly bad at telling you when you're trashing the heap as long as your trashing falls nicely within the bounds of existing objects :p
[17:22] <desrt> i guess you used always-malloc, of course...
[17:24] <mterry> desrt, probably not.  this was a relatively simple valgrind run
[17:24] <desrt> ah.  you should always do that :p
[17:24] <desrt> the slice allocator is quite good about giving out the same memory twice
[17:24] <mterry> desrt, when running valgrind?  OK
[17:25] <desrt> it makes it really hard for valgrind to detect accesses to freed objects
[17:25] <desrt> which is the sort of thing that results in what we're seeing here
[17:25] <desrt> it could be a dumb refcounting bug or something
[17:26] <mterry> desrt, documentation likes debug-blocks even better
[17:26] <desrt> i don't know what one
[17:26]  * desrt reads up :)
[17:27] <mterry> well, I guess not 'better' but 'in conjunction'
[17:31] <desrt> neat option.
[17:31] <desrt> it's quite a good one to have too
[17:33] <desrt> gslice is pretty quick about what it does with memory, particularly when it comes to its 'magazine'
[17:34] <desrt> if you tlel it "here's a 16-byte chunk of memory that i'm freeing" it will toss it in a list and give that chunk back out to the next person who asks for a 16-byte chunk of memory with no additional checking at all
[17:34] <desrt> so you can do some pretty funky things, as you might imagine
[17:35] <desrt> like donating malloc()'d or mmap()'d memory to the next g_slice_alloc() user :)
[17:35] <desrt> (or, as in the example that was given, memory that is from the slice allocator, but the wrong size)
[18:33] <chrisccoulson> pitti - did your firefox stop crashing btw? i just had a look on crash-stats, and the last submitted crash report due to the globalmenu was on 4th feb
[18:52] <didrocks> mterry: you can give me all the utouch-* stack + girr
[18:52] <didrocks> ginn
[18:52] <mterry> didrocks, hah!  will do
[18:52] <didrocks> mterry: I've already done the work when checking for NEWing :)
[18:53] <didrocks> mterry: so, just a quick look again for the MIR, but all is basically done :)
[18:53] <mterry> didrocks, cool
[18:53] <didrocks> mterry: will get to it tomorrow
[18:53] <didrocks> now, time for dinner + some work offline!
[18:53] <bcurtiswx> cya didrocks
[18:53] <didrocks> see you bcurtiswx
[19:08] <RoAkSoAx> anyone might have an idea why a .desktop file is not updating the path to the icon? (this software was initially created with quickly and everything was working fine till last upload)
[19:10] <mterry> RoAkSoAx, you talking about natty quickly?
[19:11] <mterry> RoAkSoAx, it started using svg icons in the latest update, maybe that's related?
[19:12] <RoAkSoAx> mterry: not really natty quickly, but I uploaded new release of testdrive couple weeks ago and during the build process the icon path for the .desktop file was updated correctly. I uploaded a new testdrive earlier this week and the path has not been updated in the .desktop file. I'm building in pbuilder's today, and the path gets updated correctly
[19:13] <mterry> RoAkSoAx, oh, odd.  so quickly didn't change...
[19:14] <RoAkSoAx> mterry: nope the setup.py hasn't been touched for a long time
[19:14] <RoAkSoAx> and quickly just updated the .quickly file version
[19:15] <RoAkSoAx> but that the weird thing is that the package in the archives does not update the path of the image for the .desktop file, while the ones I'm building right now in pbuilders do
[19:15] <RoAkSoAx> I guess I'll just have to upload a new testdrive and see if it is fixed
[19:26] <chrisccoulson> seb128 - are you able to accept firefox for me please? (it's sat in binary NEW atm)
[19:26] <seb128> chrisccoulson, hum, how can I money that? :-)
[19:27] <chrisccoulson> heh :)
[19:27] <seb128> chrisccoulson, can do, is the new binary for main or universe?
[19:27] <chrisccoulson> i'll buy you a beer at UDS ;)
[19:27] <chrisccoulson> seb128 - for main, i would like to build icedtea-plugin against it
[19:29] <seb128> chrisccoulson, done
[19:29] <chrisccoulson> seb128 - excellent, thanks :)
[19:30] <seb128> chrisccoulson, yw
[21:27] <jcastro> mterry: so the eclipse menu was too scary?
[21:27] <mterry> jcastro, yeah  ;)
[21:28] <mterry> jcastro, I'll revisit it if no one else does
[21:28] <dobey> rodrigo_: around?
[21:29] <jcastro> mterry: on the plus side hopefully you're not permanently damaged from the experience, heh
[21:29]  * mterry hopes
[22:26] <seb128> robert_ancell, hey
[22:26] <robert_ancell> seb128, hello
[22:27] <seb128> robert_ancell, how are you?
[22:27] <robert_ancell> good
[22:27] <seb128> robert_ancell, great ;-)
[22:27] <seb128> robert_ancell, can you make sure that the versions update you do keep a clean stdout?
[22:28] <seb128> robert_ancell, otherwise the cron job sends an email with the log every time it runs
[22:28] <robert_ancell> it does, doesn't it?
[22:28] <robert_ancell> oh, so that's why you did that
[22:28] <seb128> no, it sends email about build records
[22:28] <robert_ancell> did I leave some debugging in?
[22:28] <seb128> seems you added that yesterday in your commit
[22:28] <robert_ancell> Should we just change that to 1>/dev/null?
[22:29] <robert_ancell> It's only stderr we really care about
[22:29] <seb128> "        print '    failed to build on on %s' % record.arch_tag"
[22:29] <seb128> I think is the issue
[22:29] <seb128> robert_ancell, we could as well, or just redirect stdout to a log file or something
[22:29] <robert_ancell> I think that would be better.  The log output is useful
[22:30] <seb128> k, I will rework that what I've so time to write a log on put it online in the same directory
[22:30] <seb128> so maybe just drop that print for now to stop the email spam until then
[22:31] <seb128> I will also do some cleaning tomorrow I think in the list
[22:31] <robert_ancell> clean what?
[22:31] <robert_ancell> I'll fix up the print now
[22:32] <seb128> robert_ancell, there is a bunch of lines which have no upstream versions, wrong url
[22:33] <seb128> robert_ancell, there is also some sources where we should track a stable serie
[22:33] <seb128> like glom
[22:33] <seb128> I've been reviewing some todays and taking some notes, will update the .py tomorrow
[22:34] <seb128> we should perhaps drop some sources from the list as well, i.e plymouth
[22:34] <seb128> things which are from the foundation team and we will not update
[22:35] <robert_ancell> just blacklist them so they only show on the extended view
[22:35] <seb128> could do that
[22:36] <seb128> well I just reviewed it, there is only plymouth being annoying
[22:37] <seb128> robert_ancell, btw I didn't sync farsight2, there is an ubuntu diff for it
[22:37] <seb128> changing the gst depends to good since we moving the farsight code there
[22:37] <robert_ancell> oh, I was supposed to take that one off the list, thanks
[22:44] <seb128> TheMuso, why is the espeak version 1.44.05~really-1.44.04-0ubuntu1?
[22:45] <seb128> or, you repacked it, weird version
[22:45] <seb128> rather than using current-repacked or something
[22:50] <chrisccoulson> m'eh, just got the invisible window bug again
[22:51] <chrisccoulson> i thought didrocks said that was fixed ;)
[22:51] <seb128> chrisccoulson, it's not but they go a way to trigger it reliably now and know what's going on
[22:51] <seb128> sam said he would fix it tomorrow
[22:51] <chrisccoulson> seb128 - oh, that's good :)
[22:51] <seb128> you can hide and show the desktop to workaround it
[22:51] <seb128> ctrl-alt-d
[22:52] <seb128> robert_ancell, btw do you see any compelant reason to try to get cairo 1.11?
[22:52] <seb128> or should we just stay on 1.10? I don't really trust their schedules
[22:52] <robert_ancell> not that I know of.  I'd like to have the latest because that makes support easier post-release
[22:53] <robert_ancell> how late do you think we can wait?
[22:53] <TheMuso> seb128: I had a weird problem when I uploaded it, I detailed the problem in teh changelog.
[22:53] <TheMuso> I hope to merge the latest Debian revision before FF, so hopefully that problem won't show itself again.
[22:54] <TheMuso> It had something to do with the binary files in the tarball, can't remember exactly without checking the changelog myself.
[22:56] <seb128> TheMuso, ok, yeah the changelog explain it, it's just the version you picked which is confusing
[22:57] <seb128> TheMuso, rather than doing version-repacked you did next-version...
[22:57] <seb128> robert_ancell, well, we should decide around feature freeze I guess
[22:58] <robert_ancell> seb128, interesting, why doesn't cairo show up on versions by default?
[22:58] <seb128> robert_ancell, I will check with upstream if they are a fixed schedule, but seems they started recently to roll 1.11 tarballs so I'm not really confident it will turn stable this cycle
[22:58] <seb128> they got over one cycle delay for 1.10
[22:59] <seb128> robert_ancell, it does but on the non default list...not sure why
[22:59] <seb128> do, launchpad off in 2 minutes it says
[23:00] <seb128> it's not in the germinate desktop list
[23:01] <seb128> it's in the standard one
[23:04] <seb128> ok, enough irc for today here, see you tomorrow
[23:09] <bcurtiswx> aww darn, bzr just went down...
[23:10] <bcurtiswx> sorry
[23:10] <bcurtiswx> LP went down for the bzr get etc..
[23:12] <micahg> bcurtiswx: should be about 90 minutes
[23:15] <bcurtiswx> micahg, yup plenty of time for me to go take care of dinner and clean it up. lol


[16:41] <sem> bioterror: I am not sure, I had splash kernel option switched off because the video stuttered
[16:42] <sem> I suppose I could remove the splash file and update initramfs again