[00:00] <marcoceppi> I can't remember, but probably a year or so after 2.0
[00:00] <marcoceppi> so filing a bug is a good idea
[00:00] <schkovich> marcoceppi: sure. i will file bug report; lounchpad or github?
[00:00] <marcoceppi> schkovich: launchpad
[00:00] <marcoceppi> schkovich: lmk when you do I can make sure people see it
[00:01] <schkovich> marcoceppi: thank you for assistance once again :)
[00:01] <schkovich> marcoceppi: have a nice day
[00:01] <marcoceppi> np, hopefully the core team can sort this quickly
[00:09] <schkovich> marcoceppi: it would be nice to have option to enable/disable functions per user
[00:09] <marcoceppi> schkovich: AIUI ACLs will be coming to users in 2.0
[00:11] <schkovich> marcoceppi: cool :)
[00:12] <marcoceppi> schkovich: I just did a screencap of what sharing in 2.0 looks like, since I felt bad that we weren't able to get it working
[02:10] <miken_> Is it possible to remove a service which was deployed to machine 0?
[02:11] <blahdeblah> miken_: tried "juju destroy-unit unit-name/number"?
[02:13] <miken_> blahdeblah: what I tried initially was destroy-service, which returned, but the unit is in an error state, so when I try to resolve, I just see /usr/games/sl output - I assume, warning me that if it proceeds it's going to break the env (not sure if that's something specific to the deployment environment)
[02:13] <miken_> s/but the/but as the/
[02:14] <blahdeblah> miken_: Hmmm - can't say I've seen that; Is that service deployed to other units as well?
[02:14] <miken_> Nope, just machine zero (it's the ubuntu charm with basenode)
[02:16] <blahdeblah> If it's in error state, you *might* be able to get it sorted just by "juju resolved ubuntu/0" (or whatever it's called)
[02:17] <miken_> Right - it seems I was using `juju resolve` rather than `juju resolved` . Thanks
[07:53] <jamespage> gnuoy, if you have a few seconds - https://code.launchpad.net/~james-page/charms/trusty/rabbitmq-server/tox-switchover/+merge/286139
[07:54] <gnuoy> jamespage, sure
[07:55] <gnuoy> jamespage, is the apt_cache unit test change deliberate ?
[07:58] <jamespage> gnuoy, yes - the patching was way to far down the stack
[07:59] <jamespage> gnuoy, so switched to patching cmp_revno instead
[07:59] <gnuoy> ack, it just didn't seem relevant to a move to tox
[08:00] <jamespage> gnuoy, prob is that apt is not in pypi, and I don't like relying on stuff outside of the venv
[08:00] <jamespage> it would just work tbh
[08:00] <jamespage> but its not deterministic
[08:00] <gnuoy> kk, makes sense
[08:38] <jamespage> gnuoy, well that broke osci
[08:38] <jamespage> nice
[08:39] <gnuoy> yeah, I had an inkling it might
[09:23] <jamespage> apuimedo, morning
[09:23] <jamespage> apuimedo, just running tests on https://code.launchpad.net/~james-page/charms/trusty/midonet-api/trunk/+merge/286146
[09:23] <jamespage> and then midonet-api lgtm
[09:23] <jamespage> I had to add cassandra to the tests to get the agents to generate host uuid's
[09:24] <jamespage> at least I think that was the case - also had a problem with memory on compute nodes...
[09:24] <apuimedo> mmm, It should not be necessary to have cassandra for the host uuid
[09:25] <jamespage> apuimedo, that may be surplus then - I may have got confused with midolman shutting down due to lack of memory
[09:26] <jamespage> apuimedo, let me drop that and re-check
[09:30] <apuimedo> lack of memory for sure ;-)
[09:30] <jamespage> 1.5G is not enough
[09:30] <jamespage> upped the constraint on the test to 4G
[09:36] <apuimedo> jamespage: good choice, sorry I forgot
[09:36] <apuimedo> I usually put 6G
[09:37] <jamespage> 4 works - the tests don't execute instances so there is enough
[09:41] <jamespage> apuimedo, hmm - I think cassandra is required
[09:42] <jamespage> midonet-agent won't install midolman untill the CassandraRelation is present
[09:42] <apuimedo> oh, that's right. the software does not require it, but my charm does
[09:42] <apuimedo> sorry, my bad
[09:53] <jamespage> apuimedo, ok fixed in my branch - executing all of the amulet tests now to confirm thats all ok
[09:54] <apuimedo> good
[09:54] <apuimedo> :-)
[10:45] <apuimedo> jamespage: did it work? (please say aye)
[10:45] <jamespage> apuimedo, still running but looks like it will
[10:45] <apuimedo> :-)
[10:45] <jamespage> I see a long lag on the final hook excution on midonet-api
[10:45] <jamespage> the hook is accessing the API, something times out and then it completes...
[10:45] <jamespage> but not sure what
[10:47] <jamespage> apuimedo, I think its that hang that I reported when I did my initial testing
[10:48] <apuimedo> jamespage: in my openstack env it's due to to access to the 8080 not being propertly opened by juju
[10:48] <apuimedo> haven't experienced it on maas though
[10:49] <jamespage> apuimedo, we don't have security groups turned on:-)
[10:50] <apuimedo> jamespage: anything on /var/log/tomcat/midonet* ?
[10:51] <jamespage> apuimedo, http://paste.ubuntu.com/15090189/
[10:52] <jamespage> its looping through those last few messages
[10:52] <apuimedo> from Server - jetty?
[10:55] <jamespage> apuimedo, not sure tbh
[10:55] <jamespage> that;s the midonet-api.log file
[10:57] <jamespage> apuimedo, /var/lib/juju/agents/unit-midonet-api-0/charm/hooks/host-relation-changed started running at 10:48
[10:57] <jamespage> I suspect I'll hit some sort of response timeout shortly
[11:00] <apuimedo> very odd
[11:00] <apuimedo> if you go as root in the midoent-api container
[11:01] <apuimedo> does `midonet-cli -e "host list"` show anything
[11:01] <apuimedo> or does it also block
[11:01] <apuimedo> ?
[11:01] <jamespage> apuimedo, test just completed a pulled down the env...
[11:03] <apuimedo> ok
[11:03] <apuimedo> I guess
[11:42] <jamespage> apuimedo, ok - so looking good for https://code.launchpad.net/~james-page/charms/trusty/midonet-api/trunk/+merge/286146
[11:42] <jamespage> just running the mem tests as well to verify our firewall configuration for the midokura.com repos
[11:46] <stub> Is 1.25.3 technically a development version, or did that even/odd thing get scrapped?
[11:47] <apuimedo> jamespage: I found the reason
[11:47] <jamespage> apuimedo, pray tell?
[11:47] <apuimedo> it was blocking on random number generation
[11:47] <jamespage> apuimedo, ahhhhhhh
[11:48] <apuimedo> just tomcat things :D
[11:48] <apuimedo> I'll send a patch to change the source
[11:48] <jamespage> apuimedo, oh I remember this
[11:48] <jamespage> prng on startup used to suck
[11:52] <apuimedo> yup
[11:52] <jamespage> apuimedo, sudo apt-get install haveged
[11:52] <apuimedo> on v5 we are not using tomcat anymore
[11:52] <apuimedo> haveged?
[11:52] <jamespage> not saying thats a great solution, but it does increase entropy on virt systems
[11:53] <apuimedo> jamespage: I was planning on modifyin tomcat config to have JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom"`.
[11:53] <jamespage> that works as well
[11:53] <apuimedo> ;-)
[11:55] <jamespage> apuimedo, mem +1 as well
[11:55] <apuimedo> mem +1?
[11:57] <jamespage> it passes amulet tests...
[11:57] <jamespage> for -agent and -api
[11:57] <jamespage> running amulet for neutron-agents-midonet now as well
[12:02] <apuimedo> great
[13:22] <apuimedo> jamespage: I can merge https://code.launchpad.net/~james-page/charms/trusty/midonet-api/trunk/+merge/286146 then, right? (there's the please don't merge comment still)
[13:22] <jamespage> apuimedo, go for it
[13:22] <apuimedo> thanks
[13:22] <jamespage> I have a similar one for neutron-agents-midonet - just running the tests now
[13:23] <apuimedo> cool
[13:23] <apuimedo> thanks a lot for these improvments
[13:40] <jcastro> apuimedo: hey any luck on your zfs issue?
[13:42] <apuimedo> jcastro: it went away by itself trying for the 13th time
[13:42] <jcastro> heh
[13:44] <apuimedo> jamespage: jcastro: I would like add a package to cloud-archive for mitaka
[13:44] <apuimedo> do you know who I should be speaking with?
[13:45] <jcastro> not me, someone on james' team I would guess off the bat though
[13:45] <apuimedo> cool, thanks
[13:47] <apuimedo> jamespage: midonet-api patches successfully merged
[13:47] <jamespage> apuimedo, ack
[13:47] <jamespage> apuimedo, what's the package?
[13:47] <jamespage> it needs to go into xenial development first
[13:48] <apuimedo> jamespage: kuryr
[13:48] <apuimedo> the libnetwork driver of kuryr, more specifically
[13:49] <jamespage> apuimedo, pointer?
[13:49] <jamespage> we're very close to feature freeze, but we could always go debian first if need be - its only a new leaf package
[13:54] <apuimedo> jamespage: github.com/openstack/kuryr
[14:23] <admcleod-> anyone know why 'juju status' would give me 'error: lock timeout exceeded' ?
[14:24] <lazyPower> admcleod- is your bootstrap node out of disk space?
[14:24] <lazyPower> *model controller
[14:25] <admcleod-> lazyPower: nope
[14:25] <admcleod-> lazyPower: nowhere near
[14:25] <lazyPower> thats th eonly time i've seen that error
[14:29] <jamespage> apuimedo, https://code.launchpad.net/~james-page/charms/trusty/neutron-agents-midonet/trunk/+merge/286181
[14:29] <apuimedo> thanks jamespage
[14:32] <apuimedo> jamespage: merged
[14:32] <jamespage> apuimedo, ack
[14:33] <jamespage> apuimedo, I have some general feedback on some further improvements - observability is not that great atm; but that won't block promulgation to the curated charm set
[14:33] <jamespage> apuimedo, just letting the n-a-m tests complete...
[14:34] <apuimedo> jamespage: what do you mean with observability? You mean putting status messages?
[14:34] <apuimedo> like, connection to cassandra and zookeeper not ready
[14:34] <apuimedo> for example?
[14:34] <jamespage> apuimedo, status is one aspect yes
[14:34] <apuimedo> what else?
[14:34] <admcleod-> lazyPower: well.. removing '~/.juju/current.lock' fixed it..
[14:35] <lazyPower> admcleod- well thats something i suppose
[14:35] <lazyPower> admcleod- are you running stable or 2.0-alpha* series?
[14:35] <admcleod-> lazyPower: stable
[14:55] <jose> bdx: ping
[14:56] <jamespage> apuimedo, ok - so all promulgated
[14:57] <jamespage> https://code.launchpad.net/~charmers
[14:57] <jamespage> they will injest into the charm store in the next few hours....
[14:58] <apuimedo> yay!!!
[14:58] <apuimedo> thanks a lot jamespage! I would really appreciate an email with the suggestions to improve ;-)
[15:01] <jamespage> apuimedo, two comments on https://bugs.launchpad.net/charms/+bug/1453678
[15:01] <mup> Bug #1453678: New charms: midonet-host-agent, midonet-agnet, midonet-api <Juju Charms Collection:Fix Released> <https://launchpad.net/bugs/1453678>
[15:01] <jamespage> apuimedo, thanks for all of your work on the charms - glad to get you finally landed!
[15:11] <_Sponge> | http://ubuntuonair.com/ | 50 minutees to-go :)
[15:11] <balloons> marcoceppi, jcastro, do you guys have any ideas or interest in juju + google summer of code? projects / mentors?
[15:11] <marcoceppi> balloons: yes
[15:12] <marcoceppi> I've been trying to figure out how tasks and such for GSOC
[15:15] <balloons> marcoceppi, we just need your ideas on https://wiki.ubuntu.com/GoogleSoC2016/Ideas
[15:16] <balloons> the application deadline is Friday, but we don't need more than the snippets on the wiki page. Google has to accept our application, and then the solitication of students will happen. Ideas don't have to be fully baked just yet
[15:17] <balloons> but we do need ideas + commitment to mentor
[16:00] <apuimedo> jamespage: :-)
[16:00] <apuimedo> thanks for bearing with my inexperience in charm land
[16:00] <jamespage> apuimedo, you are most welcome....
[16:53] <jose> rick_h__: mind a quick PM?
[16:53] <rick_h__> jose: not at all
[17:05] <ryotagami> Is this the correct place to ask about charmhelpers?
[17:14] <jose> bdx: lmk when you have a sec?
[17:23] <jose> ryotagami: I'd say so. ask ahead and someone will get back soon :)
[17:24] <ryotagami> jose: OK.
[17:24] <ryotagami> http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/amulet/deployment.py#L61
[17:25] <ryotagami> Line 61, by any chance the trailing comma is a typo? I don't think branch_location takes a tuple, which the trailing comma produces.
[17:30] <stub> ryotagami: Yes, that certainly looks like a bug
[17:31] <ryotagami> Ah, OK. Glad that it is confirmed.
[20:55] <cory_fu> Reviews welcome: https://github.com/juju-solutions/layer-basic/pull/36
[20:55] <cory_fu> Now you can say `@when('config.changed.my-opt')`
[21:03] <lazyPower> nice!
[23:07] <magicaltrout> here's a random question
[23:07] <magicaltrout> if I develop a charm and I deploy it
[23:08] <magicaltrout> then it gets accepted as a recommended charm and the namespace changes
[23:08] <magicaltrout> do I have to undeploy my deployed charm to change to the recommended one?
[23:24] <rick_h__> magicaltrout: no, you can switch over to it
[23:25] <magicaltrout> thanks rick_h__ I have an up to date gitlab charm that I have to deploy for a client tomorrow but it would be nice to keep it in sync if I get it into the recommended namespace
[23:25] <rick_h__> magicaltrout: yes, the upgrade-charm takes a --switch argument that let's you move to another url
[23:25] <magicaltrout> coolio
[23:25] <rick_h__> magicaltrout: so if it gets promoted you could update-charm --switch=cs:newurl
[23:39] <agunturu> Is it possible to get the details about submitted juju action
[23:40] <agunturu> juju action status only returns job id and status
[23:42] <rick_h__> agunturu: juju action status ?
[23:42] <rick_h__> agunturu: https://jujucharms.com/docs/1.25/actions
[23:43] <agunturu> That just retrurns the job id and status
[23:44] <agunturu> The python client actually provides what actions are submitted. Just wondering if there is a verbose version.


[00:07] <lifeless> RAOF: so, is there a bug yet ?
[00:07] <RAOF> lifeless: About GTK?  Um, no.
[00:07] <RAOF> Let me fire up gdb.
[00:12] <lifeless> step 1, file a bug on launchpad.
[00:12] <lifeless> step 2, look at the gtk+2.0 package
[00:13] <lifeless> RAOF: bug 391398
[00:13] <RAOF> Yeah, just found that.
[00:14] <RAOF> I'll see if my backtrace is anything not already there.
[01:53] <danny1> i need help connecting my home wireless to ubuntu. can anyone please help me
[01:54] <RAOF> danny1: #ubuntu is where you want to be.  If that's too noisy, launchpad answers or Ubuntuforums are good places for support.
[01:54] <danny1> okay. thank you
[02:39] <ebroder> What happened to /udev/vol_id in karmic?
[02:39] <ebroder> Err.../sbin/vol_id
[03:09] <ebroder> What's the best next step for bug #395321?
[03:09] <ebroder> Subscribing ubuntu-main-sponsors?
[03:12] <ajmitch> yes, at least for the karmic stage
[03:13] <ebroder> Is that better than trying to get doko's attention?
[03:13] <ajmitch> could be, I'm not sure how busy he is
[03:14] <ebroder> (debian/control has a Vcs-Bzr of LP:~doko/python/pkg2.5)
[03:15] <ajmitch> subscribing the sponsors team is the usual route for getting the fix in, at least
[03:15] <ebroder> I guess I'm just not clear on how the procedure changes when a package seems to have an owner in Ubuntu
[03:16] <ScottK> ebroder and ajmitch: As I understand it, doko is on a 6 month rotation with Canonical OEM services so doesn't have a lot of Ubuntu time at the moment.
[03:16] <ajmitch> ScottK: ok, that'll explain why I haven't seen him around as much :)
[03:16] <ebroder> ubuntu-main-sponsors it is, then :)
[03:16] <ebroder> Thanks, ScottK
[03:17] <ajmitch> the patch looks small enough to review quickly
[03:21] <ebroder> Is there a known issue with ifup and /var/run/network/ifstate?
[03:21] <ajmitch> I haven't heard of any
[03:22]  * ebroder sighs. Time to go digging
[03:22] <ajmitch> karmic?
[03:22] <ebroder> Yeah. I'm getting "ifup: failed to open statefile /var/run/network/ifstate: No such file or directory" when I try to ifup eth0
[03:23] <ebroder> This is also a Xen dom0, though - I can't tell yet if that's affecting things
[03:23] <ajmitch> odd, I see some mentions of it in the ifenslave changelog (from a google search)
[03:24] <ebroder> (the issue is that /var/run/network/ doesn't exist)
[03:25] <ajmitch> it exists on my karmic machine that I rebooted yesterday, fwiw
[03:27] <ebroder> i'll try without the Xen hypervisor
[03:28] <ajmitch> my karmic box is also a desktop, so it runs NM which fiddles with that file
[03:28] <ebroder> Huh - doesn't happen when I'm not running with Xen
[03:28] <ebroder> Probably has something to do with how Xen plays dumb games with bridges
[03:28] <ajmitch> that would be strange
[03:29] <ebroder> Xen renames eth0 to peth0 at boot, and then creates a bridge called eth0 and adds peth0 to it
[03:29] <ebroder> It's kind of gross, really, but so is all virtualized networking
[03:29] <ajmitch> more than just a bit messy
[03:32] <ebroder> And...that time it seemed to come up fine. I <3 software
[03:37] <ebroder> Or maybe update-grub just didn't put the Xen entry back in
[03:37] <ebroder> So yeah, if I run under the Xen hypervisor, then ifup eth0 fails because /var/run/network doesn't exist
[03:37] <ebroder> But this doesn't happen if I run the normal karmic -server kernel
[03:38] <Sarvatt> thats been around since jaunty, made me scratch my head for some time trying to figure it out
[03:38] <Sarvatt> i had to add [ -d /var/run/network ] || mkdir -p /var/run/network to my /etc/init.d/networking script on my openvz vps
[03:39] <ebroder> Sarvatt: Did you ever figure out what's supposed to create /var/run/network?
[03:39] <Sarvatt> udev which is disabled
[03:39] <Sarvatt> in my case
[03:40] <Sarvatt> /etc/init.d/loopback used to create it but they moved it
[03:40] <ebroder> Looks like I'm running udev
[03:40] <Sarvatt> /lib/udev/rules.d/85-ifupdown.rules now
[03:42] <Sarvatt> it was real fun debugging that one remotely :)
[03:43] <ebroder> I guess this is more or less bug #367171
[03:44] <ebroder> Oh wait...I think this is kernel version incompatibility for me or something
[03:47] <ebroder>  * Starting kernel event manager...
[03:47] <ebroder> error getting signalfd
[03:47] <ebroder> udevd[3412]: error getting signalfd
[03:51] <ebroder> Aha - "To be able to use signalfd(), udev depends on kernel version 2.6.25 now."
[03:57] <Sarvatt> just stick that command in /etc/init.d/networking on a new line after start)  :D
[03:57] <ebroder> That works, but it's a terrible fix
[04:07] <ebroder> Ugh. I think at this point I'm just going to give up on maintaining Xen in anything after Hardy
[05:19] <alkisg> asac: hi - just notifying that I'll be here for the next hours, in case you want feedback on this: https://bugs.launchpad.net/bugs/391040
[05:52] <hyperair> fta: thunderbird-3.0 ftbfs, just to let you know =p
[05:53] <billybigrigger> is there a gnome-do ppa on launchpad that anyone is aware of?
[05:54] <billybigrigger> errr
[05:54] <billybigrigger> gnome shell i should say
[05:55] <Sarvatt> ubuntu-desktop
[05:55] <billybigrigger> say again?
[05:56] <Sarvatt> the ubuntu-desktop team ppa
[05:57] <billybigrigger> http://ppa.launchpad.net/ubuntu-desktop
[05:57] <billybigrigger> ?
[05:57] <Sarvatt> launchpad.net/~ubuntu-desktop.....
[05:57] <billybigrigger> ahh, i see it
[05:57] <billybigrigger> http://ppa.launchpad.net/ubuntu-desktop/ppa/ubuntu/pool/main/g/gnome-shell/gnome-shell_0.0.1~git20090702-0ubuntu0.1_amd64.deb
[05:57] <billybigrigger> is anyone running this on karmic yet?
[05:57] <billybigrigger> i've never seen a 0.0.1 package before :P
[05:57] <Sarvatt> yep
[05:58] <Sarvatt> you're not going to be  able to just install a deb for it though
[05:58] <billybigrigger> oh
[05:58] <Sarvatt> need the other things in there
[06:01] <ion> It’s not even 0.0.1, it’s 0.0.1~ :-P
[06:06] <TheMuso> 8/c
[06:07]  * ion tries to parse the emoticon
[06:07] <mcasadevall> *sigh*
[06:07] <mcasadevall> Is there a good way to get a crash-report on apport when it segfaults?
[06:10] <mcasadevall> ^-- pitti
[07:06] <fabbione> soren: ping?
[07:14] <pitti> Good morning
[07:15] <pitti> mcasadevall: you mean when apport segfaults? it should catch its own segfault; if that happens recursively, you lose, though
[07:15] <StevenK> Morning pitti
[07:15] <mcasadevall> pitti, I lost :-/
[07:15] <pitti> mcasadevall: python crashes?
[07:15] <mcasadevall> pitti, I posted a crash report from another machine, but I haven't bothered to setup a retracer on the ia64 porting box yet
[07:15] <pitti> mcasadevall: /var/log/apport.log?
[07:15] <mcasadevall> pitti, looks like it
[07:16] <mcasadevall> pitti, empty
[07:17] <pitti> mcasadevall: you could /etc/init.d/apport stop, ulimit -c unlimited, and call it from a shell (if it crashes that way, too)
[07:17] <mcasadevall> pitti, yeah, it did, I submitted that crash report
[07:17] <pitti> mcasadevall: it doesn't crash in gdb?
[07:18] <mcasadevall> pitti, I haven't setup the ddebs yet to try it
[07:18] <mcasadevall> (the last dist-upgrade hosed gdm on me, I'm trying to fix that first)
[07:22] <mcasadevall> pitti, mind looking at https://bugs.edge.launchpad.net/ubuntu/+source/libpango-perl/+bug/388980 (I can't request a sync on libgtk2-perl until this goes through)
[07:22] <StevenK> mcasadevall: Or we demote libgtk2-perl?
[07:23] <pitti> mcasadevall: is ubuntu-mir subscribed? I don't have mail for it
[07:23] <mcasadevall> pitti, ubuntu-mir is subscribed
[07:23] <geser> good morning
[07:25] <mcasadevall> StevenK, then we loose libgnome2-perl in main (I think)
[07:29] <pitti> done
[07:31]  * StevenK grumles at how mcasadevall didn't use the MIR template.
[07:32] <mcasadevall> StevenK, I was given permission by pitti not to when I filed the bug
[07:32] <mcasadevall> pitti, StevenK, https://bugs.edge.launchpad.net/ubuntu/+source/libgtk2-perl/+bug/372106 - care to process the sync request ;-)
[07:33] <pitti> mcasadevall: will be done during normal archive day batch processing
[07:33] <mcasadevall> sweet
[07:33] <mcasadevall> ugh
[07:34] <mcasadevall> I think GDM broke because the xubuntu-artwork package is hosed on ia64
[07:34]  * mcasadevall grumbles
[07:36] <dholbach> good morning
[07:36] <mcasadevall> morning dholbach
[07:36] <dholbach> hi mcasadevall
[07:36] <mcasadevall> how goes it dholbach
[07:37] <dholbach> good good - how 'bout you?
[07:37] <geser> Hi dholbach
[07:37] <NCommander> dholbach, trying to figure out why GDM is hanging on ia64
[07:37] <dholbach> hey geser
[07:37] <NCommander> (and why python is broken; I think I need to setup an ia64 apport retracer at some point ...)
[07:37] <dholbach> NCommander: good luck! :)
[07:38] <NCommander> dholbach, indeed. I'm hoping to have both desktop and server CDs for ia64 building today actually, and be releasable with karmic again
[07:38] <NCommander> (SPARC server is also something I'm working on as well, I still need to dehose its kernel)
[07:39] <StevenK> NCommander: It's kernel needs cryptoloop enabled, and then it will probably build
[07:39] <NCommander> StevenK, the sparc64 config is very sparse; I think its just a defconfig. I need to sitdown and fix that
[07:39] <NCommander> Then I need to talk with the kernel team with transitioning the ia64 and sparc, and powerpc kernels to remove the -smp variants, and going to -generic
[07:40] <NCommander> (and what we want the min. requirements for ia64 to be, ATM, it needs an Itanium2 processor or greater, but thats because the kernel built requiring that)
[07:40] <StevenK> NCommander: And Colin, since d-i will need to be fixed.
[07:40] <NCommander> StevenK, d-i was only broken due to a bug int he kernel packaging that caused kernels to be installed uncompressed
[07:40] <StevenK> NCommander: If you change the names, d-i needs to know
[07:41] <NCommander> StevenK, oh, right (and the seeds, and a bunch of other crap.)
[07:41] <NCommander> Ugh
[07:41] <NCommander> That's why I want to fix everything before I start playing transition the ports kernel
[07:42]  * StevenK finds himself using the word 'handwave' in an MIR again
[07:42] <NCommander> StevenK, do you plan to use Ubuntu on your SPARC box if it gets to the point where its installable again?
[07:43] <StevenK> NCommander: My Sparc box has been decomm'd and is sitting in a corner, powered off
[07:43] <NCommander> oh
[07:43] <NCommander> that answers that
[07:43]  * NCommander wonders if he's the only one to use Ubuntu/ia64 as a desktop OS ...
[07:43] <StevenK> It's a fairly slow thing, but I could be convinced to fire it up
[07:44] <NCommander> My sunfire is a freakign antique
[07:44] <NCommander> :-/
[07:44] <StevenK> It's an Ultra5, and has (ugh) non-DMA IDE
[07:44] <NCommander> Bah, even my Ultra10 is newer than that
[07:45]  * NCommander has an Ultra 10, Netra T1, Netra X1 (which I think has a faulty processor and a sunfire v120)
[07:45]  * TheMuso winces at StevenK's sparc having non-DMA IDE.
[07:45] <NCommander> the sunfire is freaking load though
[07:46] <NCommander> TheMuso, BTW, any luck w/ running down the issues w/ powerpc?
[07:46] <TheMuso> NCommander: No, I didn't look at it on the weekend. I don't know where to continue looking.
[07:47] <NCommander> TheMuso, We need to get the xserve's in the data centre updated to hardy :-/
[07:47] <NCommander> The problem is that the last time that was tried, the machines themselves panicked
[07:47] <Ryan52> NCommander: hm...libgtk2-perl's tests are still ran, you know that, right? just a few of the tests are disabled.
[07:47] <NCommander> Ryan52, ?
[07:47] <NCommander> And powerpc defaults to power off when power cycled
[07:47] <TheMuso> NCommander: Yeah, but we kinda need something more short term I think.
[07:47] <NCommander> TheMuso, *sigh*
[07:47] <NCommander> TheMuso, let me go poke infinity, maybe he has an idea, or I can beg him to update the userland and pin the kernel
[07:47] <Ryan52> NCommander: your sync request made it sound like you didn't know this.
[07:48] <NCommander> Ryan52, the changelog you posted for the Debian upload said they were disabled :-/
[07:48] <Ryan52> I said "disable the failing tests"
[07:48] <Ryan52> I didn't say "and disable the suceeding ones too"
[07:48] <Ryan52> :)
[07:49] <Ryan52> NCommander: so if you do need special xvfb flags, you still need to patch.
[07:50] <Ryan52> NCommander: or you can ask nicely and I integrate it into my rules file too so that you don't have to maintain the patch...whichever way you prefer. :P
[07:51] <NCommander> Ryan52, when I test built -2 on all architectures, it successfully built
[07:51] <NCommander> Ryan52, so no patch is needed as of yet :-) (I remember I pinged you on this in d-perl awhile ago, then found out it wasn't needed)
[07:51] <Ryan52> then I guess you don't need special options to xvfb-run anymore. *shrug*
[07:52] <Ryan52> okie doke.
[07:53]  * RAOF would really prefer it if gdm didn't keep logging him out seemingly at random.
[07:54] <StevenK> RAOF: "Feature"
[07:54] <Hobbsee> RAOF: yeah, so would I!
[07:54] <Hobbsee> at least it respawns
[07:54] <RAOF> StevenK: "Any sufficiently obscure bug is really a feature"?
[07:55] <TheMuso> thats consolekit I think.
[07:55] <TheMuso> Or is it not...
[07:56] <RAOF> Whatever it is, it seems like it _might_ be triggered by excessive typing.
[07:56] <RAOF> Just the trigger you want for a dataloss bug!
[07:57] <TheMuso> Well thats not quite what happens for me. I start a session, then randomly I loose my session, have to log in, and then it doesn't crash again for the rest of the session until I restart.
[08:00] <soren> fabbione: Dude!
[08:01] <fabbione> soren: hey man
[08:02] <fabbione> soren: got a minute or 5 for an old fart^friend? ;)
[08:02] <soren> fabbione: Sure. What's up?
[08:02] <fabbione> soren: need some help with hardy kvm :/
[08:08] <pitti> bryce: could you please check bug 377090 again? Eric says that the userspace tasks are not fixed yet
[08:13] <daurnimator_> hi all
[08:14] <daurnimator_> how to make a package and get it included in ubuntu repos?
[08:16] <pitti> daurnimator_: https://wiki.ubuntu.com/PackagingGuide
[08:17] <pitti> daurnimator_: and https://wiki.ubuntu.com/MOTU/Packages/REVU for getting it into Ubuntu
[08:17] <\sh> moins
[08:18] <Hobbsee> RAOF: where "excessive typing" is "two charactes, but only sometimes".  I seem to keep triggering it by typing on irc.
[08:19] <wgrant> Hobbsee: Same.
[08:19] <wgrant> It seems to particularly like doing it in the first couple of minutes of my first session.
[08:19] <wgrant> And there's nothing in the X log.
[08:19] <wgrant> And it's certainly triggered by typing, but not by the amount.
[08:20] <\sh> guys....when something like the jaunty kernel is complaining about acpi tables ... what do you need from the sysadmin to get it eventually fixed? mjg59 seems not to be here anymore ;)
[08:34] <geser> wgrant, Hobbsee: same here. and it seems to be prevented if ones does the re-login oneself
[08:40] <geser> wgrant, Hobbsee: seems to be bug 395595
[08:42] <wgrant> geser: Looks like it.
[08:59] <Hobbsee> geser: yeah, that'd be it.  I guess I should stop auto-logging in, then
[09:01] <ogra> hmm, so that upgrade went rather bad
[09:02] <geser> Hobbsee: just log out once after booting, auto-login will log you in automatically again
[09:02] <Hobbsee> oh
[09:02] <Hobbsee> logging out doesn't wok fo me - or at least, logs me back in again without a prompt
[09:03]  * ogra sighs ...
[09:03] <geser> yes, but after that you don't get kicked anymore (at least I doesn't get kicked after that)
[09:03] <ogra> so my gdm initscript was completely replaced by some weird wine binary
[09:03] <Hobbsee> oh, right
[09:04]  * ogra wonders whats going on here
[09:04] <Hobbsee> ogra: wine is obviously taking ove the wold.
[09:04] <ogra> grrr, and someone enabled the keyboard bell in pluse again
[09:04] <ogra> Hobbsee, well, i wouldnt mid a good merlot or rioja .... jut not on my disk !
[09:05] <Hobbsee> hehe
[09:05] <Hobbsee> indeed
[09:07]  * ogra sighs and reboots once again
[09:09] <\sh> hmm? gdm initscript replaced by wine binary?
[09:12] <ogra> mumble
[09:13] <ogra> so why does gdm suddenly show me systm users ... i surely dont want to log in as approx
[09:13] <ogra> and why does it default to the userlist
[09:13] <ogra> sigh
[09:13] <ogra> and why is my console kbd set to US again
[09:14]  * ogra thinks new gdm hurts more than it gains us
[09:15] <geser> ogra: the keyboard layout should be fixed now (in -0ubuntu2)
[09:15] <ogra> ii  gdm                               2.26.1-0ubuntu2                   GNOME Display Manager
[09:16] <ogra> it was fine in ubuntu1 for me
[09:16] <ogra> it just broke with the last reboot
[09:17] <geser> oh, right. the console layout is also broken (just checked) :(
[09:17] <ogra> ogra@osiris:~$ sudo hddtemp /dev/sda
[09:17] <ogra> /dev/sda: Hitachi HTS722012K9SA00: 41°C
[09:18] <ogra> humm, and that used to be around 30-35°C before
[09:18] <geser> ogra: listing your system user in gdm could be bug 395281
[09:18] <ogra> intrestingly its only the approx user
[09:19] <ogra> and i installed approx weeks ago
[09:20] <ogra> or reinstalled
[09:20] <ogra> so i wonder, if its the ck bug, why does it show up now and not before
[09:23] <wgrant> ogra: Did gdm 2.20 use CK for that? I remember it being more staticly defined in the config file.
[09:24] <ogra> i think the old gdm just didnt use uid's below 1000
[09:25] <wgrant> Right.
[09:25] <ogra> what really bothers me is that replacing of the initscript, thats not supposed to happen
[09:26] <pitti> ogra: right, I see the realtimekit user in gdm
[09:27] <pitti> ogra: keyboard layout works for me now, though
[09:27] <ogra> pitti, on console ?
[09:27] <ogra> it works fine under X
[09:27] <pitti> oh, haven't tested that
[09:27] <pitti> (with German layout)
[09:27] <pitti> gdm changes the console keymap? bad gdm
[09:27] <ogra> its simply wrong in tty
[09:27] <pitti> please file a bug then
[09:27] <pitti> /etc/default/console-setup is right?
[09:27] <ogra> well, it doesnt, thats the point :)
[09:28] <ogra> it did until last upgrade
[09:28] <pitti> gdm isn't supposed to set the console keymap
[09:28] <pitti> that's /etc/default/console-setup
[09:28] <pitti> and X reads it from there
[09:28] <ogra> XKBMODEL="pc105"
[09:28] <ogra> XKBLAYOUT="de,us"
[09:28] <ogra> XKBVARIANT="nodeadkeys,"
[09:28] <ogra> XKBOPTIONS="grp:alts_toggle"
[09:28] <ogra> hmm
[09:28] <pitti> "de,us"??
[09:28] <ogra> where does the us come from there ...
[09:28] <ogra> i never touched that file
[09:29] <pitti> it should be written by the installer
[09:29] <ogra> must be the gnome tool
[09:29] <ogra> well, when my X keymap was gone you suggested i should set it in the gnome keyboard tool, that has an US map by default
[09:30] <ogra> i didnt delete the us one but added the german one and clicked on "set systemwide"
[09:30] <ogra> so i guess its gnome-systemtools fault
[09:31] <pitti> ah, that would be it
[09:31] <pitti> mvo: what would be the right package for this? ^
[09:32] <pitti> (AFAIK you did the "system wide" stuff, didn't you?)
[09:32] <mvo> pitti: ubuntu-system-service
[09:32] <pitti> ogra: ^
[09:32]  * ogra removes the us kbd in the kbd properties and reboots once more
[09:32] <ogra> hey
[09:32] <mvo> but it sounds to me like we should teach console-setup about layout="one,two"
[09:33] <ogra> someone promised the system menu would have the reboot item back
[09:33] <ogra> bah
[09:33] <ogra> i only have logout here
[09:33] <pitti> it does
[09:33] <pitti> gnome-panel version?
[09:33] <ogra> lock screen and logout...
[09:33] <ogra> no idea, upgraded 20min ago
[09:33]  * ogra checks
[09:34] <ogra> 1:2.26.2-1ubuntu4
[09:34] <pitti> mvo: does console-tools actually understand several layouts? it doesn't make sense, it should just do the default one
[09:34] <ogra> ++
[09:34] <pitti> ogra: hm, that should be the fixed one
[09:34] <mvo> ok
[09:34]  * mvo fixes
[09:34]  * pitti pokes gdm for the "shows system users" issue, thanks to james_w for analyzing
[09:35] <ogra> pitti, i *had* the shutdown option yesterday, it must have been gone with todays upgrade
[09:36] <mvo> pitti: hm, so for me de,us in the console works just fine, switching keymaps with alts works too
[09:36] <mvo> ^-- ogra
[09:37] <pitti> mvo: wow, I wasn't aware that VTs could do that
[09:37] <pitti> mvo: is "both alts" hardcoded there?
[09:37] <mvo> I think it reads it from xkboptions
[09:37] <pitti> ah
[09:37] <mvo> XKBOPTIONS="grp:alts_toggle"
[09:37] <pitti> nice
[09:37] <mvo> yeah
[09:38] <mvo> so gdm does not do anything to the keymap? or does it read the /etc/default/console-setup file?
[09:38] <pitti> mvo: gdm really shouldn't
[09:39] <pitti> if it does (by default), it's a bug
[09:39]  * mvo pokes it a bit
[09:39] <pitti> mvo: hal reads /etc/default/console-setup, and X.org reads it from hal
[09:39] <ogra> console-setup is right now
[09:39] <ogra> the keyboard isnt though
[09:39] <pitti> gdm doesn't even have an UI for setting the keymap
[09:39] <pitti> so it shouldn't mess with it
[09:39] <ogra> XKBMODEL="pc105"
[09:39] <ogra> XKBLAYOUT="de"
[09:39] <ogra> XKBVARIANT="nodeadkeys"
[09:40] <ogra> XKBOPTIONS="grp:alts_toggle,altwin:menu"
[09:40] <ogra> still US kbd on tty
[09:40] <mvo> ogra: so on the console you also got us?
[09:40] <mvo> hmm
[09:40] <ogra> mvo, *only* on ttys
[09:40] <ogra> its right in X
[09:40] <pitti> ogra: you rebooted after this? or restarted whichever init script reads it?
[09:40] <ogra> rebooted
[09:40] <mvo> ogra: does it work if you run /etc/init.d/console-setup start manually?
[09:41]  * ogra tries
[09:41] <pitti> console-setup:# Short-Description: Set console font and keymap
[09:41] <pitti> hmm
[09:41] <ogra> mvo, yes
[09:41] <ogra> race ?
[09:41] <mvo> ogra: I suspect its run too late then for some reason
[09:41] <ogra> yep
[09:42] <ogra> i dont know if it still runs from initramfs (it once used to)
[09:42]  * ogra does an update-initramfs and reboots
[09:42] <saispo> hi
[09:42] <mvo> ogra: I think that is the problem, for me LAYOUT=de,us seems to work fine
[09:42] <saispo> have you planned to sync the kernel git with the latest update ?
[09:43] <TheMuso> saispo: 2.6.31-rc2 was uploaded a few hours ago.
[09:43] <saispo> TheMuso: for hardy LTS excuse me :)
[09:44] <TheMuso> saispo: oh ok then. :)
[09:45] <ogra> initramfs -> didnt help
[09:46] <ogra> so the initscript needs to move
[09:46] <ogra> though thats run in rcS
[09:46] <ogra> i dont get how it can be to late
[09:48] <saispo> TheMuso: you think, it will be sync soon ? :)
[09:49] <ogra> TheMuso, please disable the keyboard bell in terminals again in pulse, the "clonk" if i reach the beginning of a line makes me mad
[09:49] <ogra> ugh ... /etc/rc2.d/S12915resolution how did that get there
[09:51] <ogra> ogra@osiris:~$ LANG=C sudo apt-get remove --purge 915resolution
[09:51] <ogra> ...
[09:51] <ogra> Package 915resolution is not installed, so not removed
[09:51] <ogra> ...
[09:51] <ogra> ogra@osiris:~$ ls -l  /etc/rc2.d/S12915resolution
[09:51] <ogra> lrwxrwxrwx 1 root root 23 2008-04-10 17:26 /etc/rc2.d/S12915resolution -> ../init.d/915resolution
[09:51] <ogra> i'm pretty sure i *never* had 912resolution installed on this machine
[09:52]  * ogra cries ... whats going on with my laptop
[09:52] <pitti> /usr/share/initramfs-tools/scripts/init-top/console_setup:if [ -f /etc/console-setup/cached.kmap.gz ] && type loadkeys >/dev/null; then
[09:53] <pitti> ogra: ^
[09:53] <pitti> it seems that it does really weird things in initramfs
[09:53] <pitti> it doesn't use setupcon, etc.
[09:53] <ogra> its only a fallback so you have your keyap in busybox
[09:53] <ogra> iirc
[09:53] <pitti> right
[09:53] <ogra> cjwatson would know more
[09:54] <pitti> ogra: so calling the init script manually works for you, right?
[09:54]  * ogra doesnt get where that 915resolution comes from
[09:54] <ogra> yeah, that changes the font and makes the kbd work right
[09:54]  * ogra doesnt get either why purging it doesnt remove the initscript
[09:54] <pitti> ogra: you have /etc/rcS.d/S49console-setup ?
[09:54] <ogra> yes
[09:55] <pitti> ogra: could you try booting with "text", to not start gdm at all? just to check whether gdm messes it up again?
[09:55] <ogra> ok
[09:55] <pitti> rescue should also work
[09:55] <ogra> i'm not sure its gdm related at all though
[09:56] <ogra> might just be Keybuk's fault anyway :P
[09:57] <icarus901> it's new style kernel mode setting for the intel graphics, rather than leaning on the userspace xorg driver
[09:57] <icarus901> nastiness
[10:00] <ogra> same issue in text mode
[10:02] <mvo> ogra: do you have "Setting up console font and keymap" at all in the boot log?
[10:03]  * ogra sighs and reboots again without splash ...
[10:03] <ogra> indeed i only added text
[10:03] <mvo> :)
[10:03] <ogra> oh
[10:03] <ogra> my shutdown item in the menu is back
[10:03] <ogra> intresting
[10:05] <apw> slangasek, james_w, would either of you be able to cast your eye over a kernel hanging out in binary new for me
[10:11]  * ogra curses about unstoppable fsck without splash
[10:12] <ogra> mvo, it does the right thing without splash ... BUT ... i have no äöü or any other special chars at the login prompt
[10:12] <ogra> which is kind of weird
[10:12] <ogra> though the delay through fsck might indeed have hidden the race
[10:13] <ogra> (since when do we check after 20 mounts btw, it used to be 30)
[10:14]  * ogra reboots once again without splash to make sure the fsck didnt influence it
[10:18] <ogra> ok, its definately usplash related
[10:19] <ogra> i reproduced it twice with and without splash makes the difference
[10:20] <ogra> (though the behavior of the login prompt is intresting)
[10:21] <ogra> hrm
[10:21] <silidan> guys what needs to go wrong to have working system except that dpkg, apt-get and synaptic segfault?
[10:21] <ogra> compiz stopped working as well
[10:21] <ogra> and cant be enabled again
[10:21] <cjwatson> ogra: I'm aware that console-setup isn't setting up ttys properly right now - it's nothing to do with the new gdm, as the bug has been open for a couple of weeks
[10:22] <cjwatson> ogra: workaround: 'sudo setupcon' from a virtual console after boot
[10:22] <ogra> yeah, i noticed its not gdm
[10:22] <ogra> it was just my first shot since gdm messed with my kdb settings in X before
[10:23] <cjwatson> ebroder: vol_id was replaced by blkid
[10:23] <ebroder> cjwatson: I saw that. Thanks
[10:24] <ogra> mvo !
[10:25] <ogra> /etc/xdg/compiz/compiz-manager: 1: /dev/sda1: Permission denied
[10:25] <ogra> /etc/xdg/compiz/compiz-manager: 2: tmpfs: not found
[10:25] <ogra> /etc/xdg/compiz/compiz-manager: 3: proc: not found
[10:25] <ogra> /etc/xdg/compiz/compiz-manager: 4: sysfs: not found
[10:25] <ogra> /etc/xdg/compiz/compiz-manager: 5: varrun: not found
[10:25] <ogra> /etc/xdg/compiz/compiz-manager: 6: varlock: not found
[10:25] <ogra> whats THAT !?!
[10:25] <ogra> (from my .xsession-errors)
[10:26] <ogra> ERR
[10:26] <ogra> /usr/bin/compiz: 456: /usr/local/bin/compiz: not found
[10:26] <RAOF> Looks like you might have some crazy stuff in /etc/xdg/compiz/compiz-manager
[10:26] <ogra> (no, i never compiled compiz in my life ... to prevent the question)
[10:27] <ogra> yes, i seem to have the content of mtab in there
[10:27] <RAOF> That's not going to go well :)
[10:27] <ogra> obviously
[10:28] <ajmitch> ogra: that's interesting...
[10:28] <ajmitch> COMPIZ_BIN_PATH="/usr/local/bin/" # For window decorators and compiz
[10:28] <ajmitch> in /usr/bin/compiz
[10:28] <ogra> well, still
[10:28] <ogra> i shouldnt have my mtab in /etc/xdg/compiz/compiz-manager
[10:28] <ajmitch> it looks a bit funny :)
[10:28] <silidan> yesterday i properly shutdown my system today i booted and now i wanted to start some system tools (synaptic, apt-get, dpkg, some from system->administration) but all seem to segfault
[10:29] <RAOF> ajmitch: No, that's what's meant to be in there; the config from /etc/xdg/compiz/compiz-manager overwrites that default.
[10:29] <ogra> no filesystem errors anywhere though
[10:29] <ogra> ogra@osiris:~$ sudo ls /lost+found/
[10:29] <ogra> #524291  #560422  #688923
[10:29] <ogra> hmm
[10:29] <ajmitch> RAOF: right, /etc/xdg/compiz/compiz-manager looks normal on here
[10:30] <ajmitch> time for that emergency backup?
[10:31] <ogra> i only got one of my home
[10:31] <silidan> yesterday i properly shutdown my system today i booted and now i wanted to start some system tools (synaptic, apt-get, dpkg, some from system->administration) but all seem to segfault,  how can i find out whats going wrong?
[10:31] <mvo> silidan: did you try rm /var/cache/apt/pkgcache.bin
[10:31] <ogra> no need for backups of the system, i just reinstall if needed
[10:31] <ogra> but i'd like to find the reason
[10:31] <silidan> mvo: no yet will try
[10:32] <silidan> segfault too
[10:32] <silidan> mvo: segfault too
[10:32] <silidan> means i also get a segfault for rm command
[10:32] <cjwatson> if dpkg is segfaulting then /var/cache/apt/pkgcache.bin is not at fault on its own
[10:32] <cjwatson> you probably have a corrupted library file on your disk
[10:32] <silidan> no
[10:33] <silidan> it seems sudo segfaults
[10:33] <silidan> rnm works in home dir
[10:33] <cjwatson> two choices: (a) you're experienced enough to figure out which file is broken and restore it from a rescue CD or whatever (b) back up your data and reinstall
[10:34] <silidan> yep sudo segfaults
[10:34] <silidan> so it may not be synaptic or dpkg but sudo itself
[10:34] <silidan> yep synaptic wihtout sudo works
[10:34] <silidan> so what can cause sudo to segfault?
[10:35] <cjwatson> broken executable file, broken library file, or code bug in any of those
[10:36] <cjwatson> a segmentation fault happens when a program attempts to access memory which is not mapped for its use; it can happen for all kinds of reasons but they are always either bugs or file corruption
[10:36]  * ogra has a translation question for mvo "Für Ihr System ist kein composite-fähiger Grafiktreiber verfügbar, oder der aktuelle unterstützt es bereits."
[10:36] <cjwatson> sudo *always* segfaulting is probably filesystem corruption though
[10:36] <cjwatson> please visit #ubuntu for recovery help
[10:37] <silidan> i had these kind of issues before but they magicaly fixed themselves after reboot, and they also magically appear from time to time after bootup
[10:37] <ogra> so either i dont have a composite capable driver or the current one already supports composite ?!?
[10:37] <cjwatson> then you have hardware trouble ...
[10:37] <cjwatson> with those symptoms I'd personally suspect bad RAM. use the memory test from an Ubuntu CD
[10:37] <silidan> ok
[10:37] <silidan> ill be back
[10:37] <cjwatson> please not here
[10:37] <cjwatson> this is a #ubuntu kind of thing
[10:38] <silidan> ok
[10:40] <mvo> ogra: urg, I have to look what is causing this message, but I think the tool we use to querry for the composition support in the driver is rather limited
[10:41] <ogra> it could just say "might or might not work" :)
[10:41] <ogra> shorter but says the same :)
[10:41] <ogra> /sbin/ldconfig.real: /usr/lib/libopcodes-<IP_ADDRESS>90704.so is not an ELF file - it has the wrong magic bytes at the start.
[10:41] <ogra> ohg
[10:42] <ogra> probably time to downgrade binutils
[10:47] <ogra> [    1.261079] ACPI Warning: \_SB_.PCI0.SATA.PRT0._GTF: Return type mismatch - found Integer, expected Buffer 20090521 nspredef-940
[10:47] <ogra> hmm
[10:47] <souphorn> Is there any way that I can write actionscript and release swf file?
[10:48] <souphorn> in ubuntu
[10:48]  * ogra goes to #ubuntu-kernel
[10:51] <wgrant> souphorn: You probably want #ubuntu.
[12:30] <TheMuso> Is it just me, or is LP not currently closing bugs?
[12:30] <TheMuso> with uploads.
[12:41] <geser> TheMuso: examples?
[12:53] <TheMuso> meh don't mind me, I know why.
[13:02] <roshan08> hi all, i am writing a desktop app for blogging, how does a deb gets included in the ubuntu repo
[13:06] <TheMuso> roshan08: You might be better asking in #ubuntu-motu.
[13:07] <roshan08> TheMuso, ok
[13:50] <pitti> cjwatson: would you kill me if I told you that you need to modify the installer for autologin again?
[13:50] <pitti> cjwatson: just found bug 395861, and I'd rather fix it to use /etc/gdm/custom.conf (which is what upstream uses
[13:51] <ogra> pitti, oh, doesnt that imply that all the gdm-cdd.conf files need fixing too ?
[13:52] <pitti> ogra: no, that just overrides /etc/gdm/gdm.conf
[13:52] <ogra> right, but they surely need adjustment to the new gdm
[13:52]  * Hobbsee cheers pitti on
[13:53] <pitti> cjwatson: I added an oem-config task and assigned it to you
[13:54] <TheMuso> ogra: From what I have heard, gdm uses gconf for settings now.
[13:54] <pitti> it still reads gdm.conf and custom.conf for stuff like autologin, etc.
[13:55] <TheMuso> pitti: Right, thats kinda surprising, but kinda not either. :)
[13:57] <cjwatson> pitti: fine
[14:18] <\sh> damn...now even ubuntu-devel ML is being crowded by this mono issue
[14:18] <pitti> mvo: any idea what needs to happen in bug 368580? just update a .desktop file?
[14:18] <pitti> mvo: (but I guess these .desktop files are autogenerated)
[14:19] <mvo> pitti: yes, a update to the desktop file and/or a override in the generation
[14:19] <pitti> mvo: for a SRU, fixing the .desktop file would probably work, but you wouldn't do that for the dev release, I guess?
[14:20] <mvo> pitti: do you think we want to sru that?
[14:20] <mvo> pitti: yeah, for the dev I will add a override
[14:20] <mvo> pitti: I can do that once I finished fighting with vte
[14:20] <pitti> mvo: I'm inclined to, WDYT?
[14:21] <mvo> pitti: if aMule isa important app (I guess it is for a lot of users) then yes
[14:21] <cjwatson> pitti: should I just overwrite any existing custom.conf, or does the code need to take care to account for an existing file there?
[14:21] <cjwatson> hmm, apparently the package ships a file
[14:22] <cjwatson> probably need to be careful to put it back, then
[14:22] <pitti> cjwatson: the package ships a default skeleton
[14:22] <pitti> cjwatson: didn't the jaunty gdm do the same?
[14:22] <cjwatson> yes but we were just editing gdm.conf then
[14:22] <pitti> just named gdm.conf-custom ?
[14:22] <pitti> OIC
[14:22] <cjwatson> so it was pretty obvious that we needed to keep a copy
[14:23] <pitti> brb, testing new gdm
[14:56] <Q-FUNK> howdy!  what do I need to do to get someone to look into bug #194140 ?
[14:58] <Q-FUNK> this bug has been present since way before Hardy.
[15:00] <Q-FUNK> it's a mere dependency cycle between two binaries from the same source package.
[15:26] <ion> pitti: I’d just run the upgrade from X in screen, relogin when needed and attach back to the screen. :-)
[15:26] <ion> pitti: In fact, i run every single upgrade in screen anyway.
[15:26] <pitti> that works, too
[15:26] <pitti> but I didn't want to give ten different options
[15:26] <ion> Isn’t screen installed by default?
[15:27] <azeem_> no
[15:27] <ion> Ah, ubuntu-desktop depends on it, not ubuntu-standard. Scratch that, then.
[15:29] <soren> kees: What ended up being the replacement for "chpasswd -e"?
[15:34] <mvo> pitti: I uploaded a fixed package for #368580
[15:41] <pitti> mvo: thanks! *hug*
[15:41] <pitti> mvo: was your last comment really meant for this bug?
[15:41] <pitti> it's not an upgrade issue at all
[15:42] <ion> Cool, the crashkernel thing works. (The crash is probably not worth even reporting, since it’s the proprietary bcmwl driver hacking the system with a dwarven war axe, though.)
[15:48] <mvo> pitti: greasemonkey
[15:48] <mvo> pitti: I added a comment that the previous comment was bogus :)
[15:48] <mvo> pitti: and added a test-case etc
[15:49] <mvo> pitti: should be good now, karmic is getting it with the next data extraction (running now)
[15:49]  * pitti hugs mvo
[15:51] <NCommander> doko, kees, ping? I need some assistance on a toolchain issue involving custom ldscripts, and I was hoping you might be able to give me a hand
[15:52]  * mvo hugs pitti
[15:57] <doko> NCommander: well, if I can help ... didn't write one yet
[15:58] <NCommander> doko, we're having issues with redboot building against our toolchain, specifically libc.a wants a lot of sections involving .tbss and the other threaded bits of the ELF headers which wasn't an issue w/ earlier glibcs
[15:58] <NCommander> doko, is there a sane way to build against newlib with our existing toolchain?
[15:59] <NCommander> which is possibly the only way to get a sane end-result
[16:00] <NCommander> doko, brb, phone call
[16:00] <doko> NCommander: we do build cross compilers as part of our toolchain packages as well, e.g. binutils-hppa64, gcc-hppa64, or -spu. you could do that for a newlib target configuration as well
[16:05] <Keybuk> pitti: you realise your instructions won't work if they're on a WPA wireless network? :)
[16:06] <pitti> Keybuk: does nm shut down WPA on session stop?
[16:06] <Keybuk> pitti: of course
[16:06] <Keybuk> pitti: the key comes from the user's session
[16:06] <pitti> sure, that's for starting it
[16:06] <ion> System settings in n-m ftw.
[16:06] <pitti> but I wasn't aware that nm tears down the connection
[16:06] <Keybuk> it seems to
[16:06] <pitti> hmm; screen FTW then
[16:07] <ion> setsid apt-get ... from the X session? :-)
[16:07] <pitti> sudo rm /var/lib/dpkg/info/gdm.prerm
[16:07] <pitti> before the upgrade
[16:07] <Keybuk> ion: shouldn't matter overly
[16:07] <Keybuk> apt might get killed
[16:07] <Keybuk> but dpkg will carry on
[16:07] <ion> --download-only dist-upgrade under the session, dist-upgrade from virtual console might work as well.
[16:09] <pitti> jdstrand: FYI, firefox-3.5 was verified in jaunty-proposed, so it's good to go now
[16:09] <jdstrand> pitti: ok
[16:09] <pitti> jdstrand: shall I copy that to -updates, or you to -security?
[16:10] <pitti> (I guess we want to do both)
[16:10] <jdstrand> pitti: I'll do both, just to make it easier
[16:10] <pitti> 'k, thanks
[16:10] <asac> thanks folks!!
[16:11] <jdstrand> np
[16:16] <soren> I have a gzip'ed file I'd like to extract. It
[16:16] <soren> Whoops
[16:17] <soren> I have a gzip'ed file I'd like to extract. It extracts to a huge file, with big gaps in it, so I'd like to make sure it's stored sparsely. How to do?
[16:17] <NCommander> doko, I'm trying to avoid that if at all possible; hence the question on using the standard toolchain against newlib
[16:18] <jdstrand> pitti, asac: copied xulrunner-1.9.1 1.9.1+nobinonly-0ubuntu<IP_ADDRESS> and firefox-3.5 3.5+nobinonly-0ubuntu<IP_ADDRESS> to -security and -updates
[16:18] <asac> ack
[16:18] <jdstrand> pitti: will you handle the closing of the bug?
[16:18] <jdstrand> (I don't remember which it is off hand...)
[16:18] <NCommander> doko, basically, the issue is that we can't statically link against glibc in a case where we did because it mucks things up. We were only linking against libc because libgcc had symbols that were dependent on it
[16:18] <pitti> jdstrand: that should happen automatically, but I'll look
[16:19] <jdstrand> oh ok, I wasn't sure about the -proposed -> -updates bit in LP
[16:20] <cjwatson> soren: google gunzip sparse, first hit
[16:21] <soren> cjwatson: Ah, "cp /dev/stdin"! Of course. I was trying to use tar with very little success. Thanks!
[16:22] <asac> jdstrand: i think the xulrunner one wasnt properly marked in changelog. i will close it manually now
[16:22] <liw> soren, that'd be a cool option to have in gzip (or a cool utility to write for moreutils, actually)
[16:23] <cjwatson> gzip yes, certainly. I'm not sure there's much point in wrapping cp --sparse=always /dev/stdin $foo in moreutils, though
[16:24] <asac> done
[16:24] <jdstrand> asac: thaniks
[16:24] <jdstrand> thanks
[16:24] <liw> cjwatson, hmm, assuming /dev/stdin works in all environments, yeah (and all environs have gnu cp, of course)
[16:24] <cjwatson> though admittedly an adverbial version (sparse gunzip ...) would be neat-ish
[16:25] <liw> for perfomance, gunzip --sparse would be great,though: no point in piping terabytes of NUL bytes to another tool that will just ignore them
[16:26] <cjwatson> yeah
[16:26] <NCommander> doko, if we need a cross-toolchain, then newlib must be built as part of the build, else the C++ toolchain FTBFS'es
[16:26] <NCommander> doko, (--with-newlib must be passed, and the newlib and libgloss symlinks will have to be setup)
[16:26] <cjwatson> especially since it's probably coming from about half a dozen bytes of the compressed file anyway :-)
[16:27] <doko> NCommander: well, we have the newlib package. so maybe just build a cross compiler from a new source package, build-depending on newlib-source, binutils-source and gcc-4.4-source?
[16:28] <NCommander> doko, that's what I currently wanted to do, but it was shot down as unacceptable.
[16:28] <NCommander> (and my current package does :-/)
[16:28] <NCommander> Well, more specifically, redboot-imx builds it as part of its rules, and then uses the newly built cross-compiler to spit out the proper binary
[16:28] <doko> NCommander: why was it shot?
[16:29] <NCommander> doko, its preferable to build w/ the in-archive toolchain
[16:29] <NCommander> (which is what we did for jaunty, but the hack to make that work broke miserably)
[16:31] <NCommander> doko, due to changes in how the symbols used between libgcc and libc.a changed, it causes the binary to bloat from 160kb to 1.2MB even after the ELF headers are stripped with objcopy
[16:31] <NCommander> doko, (the resulting binary doesn't work either)
[16:45] <pitti> lool: thanks for fixing dk-p
[16:55] <pitti> lool: I'll test the patch now, and apply it to the Debian package (I'm about to do an upload anyway)
[17:03] <geser> pitti: just curious: will postgresql-8.4 make it into karmic?
[17:03] <pitti> geser: I planned to, yes
[17:07] <ogra_> doko, would newlib be suitable for main ? in case NCommander gets that working it would become a build-dep of redboot
[17:07] <ccheney> which program regenerates the config.sub/config.guess symlinks?
[17:08] <ccheney> i thought it was libtoolize but it doesn't seem to do it
[17:08] <liw> ccheney, autotools-dev?
[17:08] <ogra_> cjwatson, the ltsp guys were nagging me, is there any ETA when we will see mount --union ? (stgraber is pretty unhappy with the slow boots)
[17:09] <cjwatson> ogra_: ask the kernel folks, not me ...
[17:09] <ogra_> ok, well, i though since you are affected as well you might know ... pure lazyness, sorry :)
[17:09] <cjwatson> ccheney: automake does it if your program uses automake; otherwise copy manually
[17:10] <cjwatson> ogra_: sorry, I've seen it being worked on but don't know the exact current status
[17:10] <ogra_> yeah, i'll ask the the source ;)
[17:10] <doko> ogra_: why not? we would only keep newlib-source in main
[17:10] <ccheney> thanks guys :)
[17:10] <ccheney> i had to use --add-missing which is what i forgot earlier
[17:11] <ogra_> doko, great, just wanted to be sure ...
[17:13] <NCommander> ogra_, bust on using newlib
[17:14] <NCommander> ogra_, stack-protector gets in the way; /usr/lib/gcc/arm-linux-gnueabi/4.4.0/libsupc++.a(eh_alloc.o): In function `global constructors keyed to eh_alloc.cc':
[17:14] <NCommander> (.text._GLOBAL__I_eh_alloc.cc+0x90): undefined reference to `__stack_chk_guard'
[17:14] <NCommander> ogra_, so using an alternate libc just got shot down :-/
[17:15] <NCommander> (just for reference sake, -fno-stack-protector is passed and used, the problem is the internally GCC libraries use it; that only matters when trying to change libcs)
[17:16] <NCommander> ogra_, I'm out of ideas again, unless doko or kees can figure out how to make the linker script happy
[17:16] <ogra_> hmm
[17:17] <kees> NCommander: sorry, I've never played with linker scripts before.  :(
[17:17] <NCommander> bust 2.0 :-/
[17:17] <ogra_> do you have a full build log you can upload ?
[17:18] <ogra_> s/upload/pastebin/
[17:18] <doko> NCommander: configure with --disable-ssp
[17:19] <doko> NCommander: or does linking with -lssp_nonshared help?
[17:19] <NCommander> doko, that isn't the problem
[17:19] <NCommander> doko, oh, right, no, this is using the stock GCC in archive (we're trying to avoid rebuilding GCC if at all possible)
[17:23] <cody-somerville> superm1, Is the Ubuntu DVD a live cd or d-i based installer or just provide a pool of packages or what?
[17:29] <NCommander> -rwxr-xr-x 1 mcasadevall mcasadevall 2.8G 2009-07-06 12:30 redboot.bin
[17:30] <NCommander> ogra, ^
[17:30] <NCommander> I think I won the worlds largest redboot contest ...
[17:30] <ogra> well, e just need to ask the SoC vendors to add a bit more flash space :)
[17:32] <cjwatson> cody-somerville: it's both
[17:32] <cjwatson> cody-somerville: you get to choose at boot time
[17:39] <superm1> cody-somerville, it's a live cd
[17:49] <cjwatson> superm1: it's both
[17:51] <Keybuk> eep.  I just came up with a valid reason to use both sigsetjmp() and a nested function in the same place
[17:51] <Keybuk> I feel dirty
[18:05] <NCommander> doko, ping
[18:07] <NCommander> doko, basically, is it possible without excessive amounts of pain to add a new cross-compiler to gcc-4.4, targeting arm-none-gnueabi, being built on only i386, and building the C, C++, and newlib compilers in single-pass mode?
[18:07] <NCommander> doko, (that is to say, setting up the necessary symlinks)
[18:09] <doko> NCommander: just leaving for today. why would that be simpler than a separate source package build-depending on gcc-4.4-source?
[18:10] <NCommander> doko, it doesn't seem acceptable based on what I've been told, hence the problem
[19:17] <spotter> new gdm is really broken, right?
[19:19] <liw> spotter, see<EMAIL_ADDRESS>[19:22] <spotter> is one of the known bugs "restarting your session" in the middle?
[19:36] <cjwatson> spotter: yes, see the -devel-announce post liw alluded to
[19:38] <spotter> I did, didnt' see any reference to bugs people have
[19:38] <spotter> though for some reason I only get kicked out once, pretty quickly
[19:38] <spotter> after that its stable
[19:38] <spotter> albiet weird as it moved from vt1 to vt7
[19:39] <cjwatson> the announcement refers to bug 395302
[19:39] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000586.html
[19:42] <spotter> cjwatson, right, but this isn't on upgrade
[19:42] <spotter> this is every time I use it
[19:43] <cjwatson> oh, right. I don't know then
[19:43] <spotter> I upgraded w/o a problem from console
[19:43] <spotter> also on "restart" it seems to mess up my vt's
[19:43] <cjwatson> but session dying isn't necessarily gdm of course
[19:43] <spotter> they are a mash of colors now
[19:43] <spotter> like half my display
[19:43] <spotter> could be an ati bug I guess
[20:16] <akos_> Hi! The GNOME 2.26 release notes says that there is a new Volume Control app (http://library.gnome.org/misc/release-notes/2.26/#rnusers.volume), however I can find only the old one (I'm using Jaunty).
[20:17] <Caesar> bryce: I think you just used your canned response on the wrong bug (#393503)
[20:21] <bryce> Caesar, thanks, the scripts have trouble distinguishing non-bug-reports from worklist/wishlist bugs unless they're formatted in a machine readable way
[20:21] <Caesar> No worries
[20:21] <Caesar> You wanna remove those tags you added or shall I?
[20:22] <bryce> go ahead, I've set to Triaged/Wishlist which should prevent further automated handling of it
[20:22] <bryce> fwiw, if you start a subject with "Please..." it is interpreted by the scripts as a workflow bug and ignored
[20:23] <Caesar> Noted
[20:28] <lool> pitti: Sorry I couldn't coordinate the dkp upload with you as the bandwidth is too crappy for ssh (and so IRC for me); I changed the Vcs stuff because I couldn't ask you to merge it in Debian first
[20:28] <lool> pitti: Thanks for testing it and pushing it to Debian then
[20:29] <lool> pitti: I'm in utopia BTW
[20:29] <lool> pitti: But I didn't do any packaging on dk yet
[21:14] <ion> pitti: Oh, btw, when upgrading from gdm 2.26.1-0ubuntu2 to 2.26.1-0ubuntu3, gdm never came back up automatically. The old version’s prerm: “* Stopping GNOME Display Manager...”, the new version’s postinst: “* Reloading GNOME Display Manager configuration...” “invoke-rc.d: initscript gdm, action "reload" failed.” (gdm reload after gdm stop just fails).
[21:26] <Kano> hi Sarvatt , is there a current iso with all xorg git updates
[21:26] <Sarvatt> nope, its going through some flux right now so i havent made one
[21:28] <olof_> I'm planning to start migrating software-properties-gtk to use policykit instead of sudo (as it is used in update-manager, and in one of the karmic blueprints), but I would need some assistance. Where should I turn to? ubuntu, software-properties-gtk or policykit?
[21:29] <Kano> Sarvatt: i need something with 2.6.31 and latest intel git
[21:29] <Kano> if you like let me know when you have got something like that
[21:29] <Kano> i am usually on that irc server
[21:29] <Kano> bye
[21:29] <Sarvatt> the packages are on edgers, why dont you do it yourself?
[21:30] <Sarvatt> even the livecd build scripts are on there
[21:30] <Sarvatt> ah he left
[21:30] <glatzor> olof_, hello. I worked on s-p-gtk some time ago.
[21:31] <glatzor> olof_, Currently I am writting aptdaemon which allows to install/remove packages using policykit. I plan to also add support for installing signatures and enabling/disabline repositories
[21:32] <glatzor> olof_, aptdaemon would already provide you a working dbus service that you could enhance.
[21:33] <olof_> glatzor: Oh, cool, I have little experience of policykit and python, but I found the first obstacle. software-properties-gtk need to access some keyrings and /etc/apt/trustdb.gpg. I don't know what to do now? Allow it to be read as root? Rewrite the fetching of keys?
[21:33] <olof_> glatzor, What is aptdaemon? Can I find info somewhere?
[21:34] <glatzor> olof_, https://launchpad.net/aptdaemon
[21:35] <olof_> glatzor, Just found it :)
[21:36] <glatzor> olof_, software-properties-gtk makes use of python-software-properties and aptsources
[21:38] <glatzor> glatzor, basically you could just call the methods of software-properties directly in the aptdaemon
[21:39] <olof_> glatzor, I did some digging in the source code and found that it uses gpg directly. Does aptdaemon provide an API for that instead?
[21:39] <glatzor> olof_, so you don't have to worry about the level things
[21:40] <glatzor> olof_, no. not yet. you would have to just "import SoftwareProperties"
[21:40] <glatzor> in aptdaemon
[21:40] <glatzor> olof_, it doesn't make sense to duplicate work.
[21:44] <ogra_> glatzor, tell that microsoft ...
[21:44] <ogra_> they duplicate our work all the time instead of invesing into ubuntu ;)
[21:45] <olof_> glatzor, Which package do I need for the SoftwareProperties module?
[21:45] <glatzor> olof_, python-software-properties, but it should be installed on every desktop system
[21:46] <glatzor> by default
[21:46] <glatzor> https://launchpad.net/software-properties
[21:46] <glatzor> There you can also find the source code
[21:48] <olof_> glatzor, I have python-software-properties installed, and tried import SoftwareProperties in a testprogram, but python can't find it
[21:49] <glatzor> olof_, sorry. the package name is softwareproperties
[21:50] <olof_> glatzor, That worked better. I will check out the source code a bit, and probably return for more questions
[21:51] <glatzor> "pydoc softwareproperties.SoftwareProperties" will give you a short overview
[21:52] <olof_> glatzor, Thanks, I'm quite new to Python, so I feel a bit lost
[21:54] <glatzor> olof_, no problem. the redesign of software-properties was also one of my first Python projects :)
[21:57] <olof_> glatzor, I just noticed that this was my starting point. I will try to be more specific. In AptAuth.py in the softwareproperties module, there is a call to /usr/bin/gpg. My idea was to use policykit to run only this command (as a starting point). Is that the way to do it, or does aptdaemon you talked about, provide a wrapper to work around this syscall?
[21:58] <glatzor> olof_, there is no need for caring about the low level system calls. softwareproperties is already a wrapper.
[21:58] <glatzor> you would have to add functions to aptdaemon which can be called by dbus. in these functions you would call the functions of software-properties
[22:00] <glatzor> policykit is only a framework to manage privileges.
[22:01] <glatzor> simplified: you can only ask the policykit service if a given user is allowed to do a given task
[22:01] <glatzor> aptdaemon already makes use of policykit and provides a rough python api for policykit
[22:03] <glatzor> olof_, at first you should take a look at the python dbus tutorial to understand how it can be used
[22:03] <olof_> glatzor, I can't find anywhere to check out the aptdaemon code.
[22:04] <glatzor> olof_, you don't need to understand dbus completely, since aptdaemon already provides all the basics for you
[22:04] <glatzor> bzr branch lp:aptdemon
[22:05] <glatzor> olof_, take a look at the aptdaemon/core.py file: The AptDaemon class provides the dbus service
[22:07] <glatzor> olof_, you don't need to use the the transaction/queuing mechanism for the repository handling
[22:08] <glatzor> olof_, GetTransactions is a very basic function that you could use as a starting point
[22:09] <olof_> glatzor,Reading the source now. Guess it will take a while to get into it :)
[22:09] <glatzor> olof_, you could try to start adding keys at first
[22:09] <olof_> glatzor, Does aptdaemon provide a method for that? Are there any example files?
[22:10] <glatzor> olof_, you can use every gpg key
[22:15] <glatzor> olof_, try to add a new function to the daemon and the client. it doesn't need to do more than just print "hello world"
[22:16] <glatzor> olof_, D-Bus methods use camel case names. So you could create a method InstallKey which accepts a file path
[22:16] <olof_> glatzor, Still trying to fit the pieces together.. do I need to run aptdaemon as a daemon, and then write a client program to interact with it?
[22:17] <glatzor> olof_, right.
[22:18] <olof_> Can I run it directly from the directory I checked out with bzr, or do I need to install the daemon first?
[22:18] <glatzor> olof_, but luckily there is already a client :)
[22:18] <olof_> glatzor, Hurray!! :) ...where?
[22:18] <glatzor> olof_, aptdaemon/client.py and aptdaemon/console.py
[22:18] <glatzor> client provides an abstraction for the client side of aptdaemon
[22:19] <glatzor> in console you can find the command line client
[22:21] <olof_> console can't find aptdaemon.. never installed python stuff by hand in ubuntu, which I guess I need to do. What to do?
[22:21] <glatzor> olof_, you can run all commands directly from the source code repository
[22:21] <glatzor> but you need to add some configuration files for dbus
[22:22] <glatzor> perhaps it is the easiest way to install the aptdaemon package
[22:23] <glatzor> https://launchpad.net/~aptdaemon-developers/+archive/ppa
[22:23] <olof_> Does setup.py have something to do with this, or do I need a .deb to install it correctly?
[22:25] <glatzor> olof_, install the aptdaemon package from the ppa
[22:26] <glatzor> olof_, afterwards you can run the daemon from the bzr directory: sudo ./aptd -td
[22:26] <glatzor> the client command line tool is aptdcon: "./aptdcon install xterm" would install xterm
[22:49] <daurnimator> is there someone that can make a libbrary into a deb for me?
[22:53] <olof_> glatzor, I'm getting dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.127" is not allowed to own the service "org.debian.apt" due to security policies in the configuration file, when trying to start the daemon
[22:53] <glatzor> olof_, do you run the daemon as root?
[22:53] <glatzor> sudo ./aptd -td
[22:53] <glatzor> the aptdaemon package is installed?
[22:53] <ScottK> daurnimator: Probably not.  You can ask packaging questions on #ubuntu-motu, but you're not very likely to find someone to just do it for you.
[22:54] <olof_> glatzor, yes
[22:55] <glatzor> olof_, "sudo /etc/init.d/dbus reload"
[22:55] <TheMuso> daurnimator: You might be better asking in #ubuntu-motu.
[22:56] <olof_> glatzor,sorry, just installed python-aptdaemon. Now it's installed, and it works
[22:57] <glatzor> olof_, ./gtk-demo.py is a small graphical demo application
[22:59] <olof_> glatzor, gtk-demo looks like a good starting point.
[23:00] <glatzor> olof_, you get earlier results with the console client
[23:00] <glatzor> olof_, it is less complex, and you don't have to care about the gui
[23:01] <glatzor> it is just "print result" :)
[23:02] <olof_> glatzor, yes... tried it to install a package. Worked just fine. Will take a look at the source code. Think I'm starting to get the hang of this. Just need to confirm a few things again :)
[23:03] <glatzor> olof_, feel free to mail me.
[23:04] <olof_> glatzor, That's probably the best way. I think I saw your address at launchpad
[23:04] <glatzor> glatzor at ubuntu dot com
[23:06] <olof_> Thanks for the help. I will try to get something together. This is probably the closest I have come to actually doing some community work after 10 years of using linux :)
[23:45] <billybigrig> anyone know how i go about finding who maintains gspca?
[23:54] <pochu> billybigrig: the webcam drivers?
[23:54] <billybigrig> yeah
[23:54] <billybigrig> .31 has broken mine
[23:54] <billybigrig> and i want to know if there's a workaround or something
[23:56] <pochu> billybigrig: the kernel team
[23:56] <pochu> billybigrig: there's #ubuntu-kernel
[23:56] <billybigrig> no answers :P everyone must be sleeping
[23:56] <pochu> :)
[23:57] <pochu> billybigrig: you could also try the mailing list if nobody replies there
[23:59] <billybigrig> i guess


[18:40] <blkperl> slangasek: why is polkit so broken...
[18:40] <blkperl> and how do i debug it
[18:43] <blkperl> oow i just core-dumped it
[19:51] <slangasek> blkperl: I don't know and I don't know


[17:41] <www2> Hi i wand to know after the 32bit drop that i can continue use of 32bit applicatopns in wine?
[17:43] <lotuspsychje> www2: come join to #ubuntu-discuss, this channel is for 19.10 support
[17:44] <tomreyn> 19.10 will drop 32-bit, so it's not strictly the wrong place IMO.
[17:45] <tomreyn> www2: see "Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?" at https://discourse.ubuntu.com/t/i386-architecture-will-be-dropped-starting-with-eoan-ubuntu-19-10/11263/2
[17:54] <www2> wine
[17:54] <www2> sorry i that this was my bash terminal
[17:58] <lotuspsychje> www2: are you using wine on 19.10?
[18:00] <www2> no current i use 18.10 i plan to do a test on a vm
[18:01] <lotuspsychje> www2: okay, read the link tomreyn adviced you
[18:02] <www2> i have read this one


[12:41] <jtv> On call: jtv || reviewing: foxxtrot || queue: [] || RC branches jump the queue || This channel is logged: http://irclogs.ubuntu.com/ || https://code.launchpad.net/launchpad/+activereviews
[18:13] <EdwinGrubbs> jtv: are you not reviewing today?
[18:13] <jtv> EdwinGrubbs: yes, but done.
[18:13] <jtv> Well, done accepting new reviews.
[18:13] <EdwinGrubbs> ok, nm.
[18:15] <EdwinGrubbs> bac: according to the kanban board, you're waiting for a review. Do you want me to take it? I have one if your bored?
[19:52] <bac> hi Edwin-lunch
[19:53] <bac> the kanban is not exactly right.  the branch has been reviewed but i'm making the suggested changes.
[21:49] <leonardr> Edwin, can you review https://code.edge.launchpad.net/~leonardr/launchpad/grant-permissions-oauth/+merge/29425 ?
[21:49] <leonardr> gary: i'd also like your opinion on the naming of the new access level and the wording of its description
[21:49] <gary_poster> leonardr: ack
[21:50] <leonardr> f'rinstance, manage_permissions might be better than grant_permissions?
[21:52] <jml> hey, I'm not around
[21:52]  * leonardr ponders that
[21:52] <jml> but if I were, I'd be asking whether this is relevant to the gpg/ssh key discussion on the mailing list
[21:52] <EdwinGrubbs> leonardr: sure
[21:53] <jml> as it is, I'm not.
[21:53] <leonardr> jml, let me take a stab at it without knowing the exact details of the current discussion, based on past discussions
[21:54] <leonardr> there is a solution to this problem that involves gpg keys and digital signatures. however, that solution is more confusing to the unskilled end-user than the 'open a web browser' solution
[21:56] <jml> hey look, lifeless and wgrant are talking about it :)
[21:56] <leonardr> all right, i'll go over there
[21:56] <jml> leonardr, I'm going to wish you the best of luck while I fetch myself a digestiv, open a novel and retire for the evening.
[22:08] <gary_poster> leonardr: From an end user perspective, Grant Permissions is a much better title because it reflects the common action (and the danger); and let's keep the code name matching it, even though "manage" is more complete and accurate.
[22:08] <gary_poster> User description wordsmithing: WDYT of changing "Not only will the application will be able to access Launchpad on your behalf, it will be able to grant access to your Launchpad account to any other application." to "The application will be able to grant access to your Launchpad account to any other application "
[22:08] <gary_poster> IOW, get rid of "Not only will the application will be able to access Launchpad on your behalf,"
[22:09] <leonardr> makes sense
[22:13] <gary_poster> cool.  Otherwise, looks good.  Thank you.
[22:42] <EdwinGrubbs> leonardr: review sent
[22:42] <leonardr> thanks


[09:36] <psivaa> cjwatson: xnox: http://pastebin.ubuntu.com/5721076/ is seen with the default raring server installations today.
[09:37] <xnox> psivaa: is that on all server jobs?!
[09:37]  * xnox ponders how to subscribe to failures on those.
[09:38] <psivaa> xnox: both i386 and amd64
[09:40] <cjwatson> hmmmm
[09:40] <psivaa> xnox: public jenkins is taking too long to load, but we have not set up email notifications for the smoke tests yet, we could do that
[09:41] <cjwatson> psivaa: new today?
[09:41] <psivaa> cjwatson: yes this failure is new and only with today's images
[09:41] <cjwatson> oh, d-i updated without seeds again
[09:42] <infinity> It sure didn't.
[09:42] <cjwatson> hmm
[09:42] <cjwatson> maybe just really unlucky timing
[09:42] <infinity> Unless something's trying to pull d-i from proposed.
[09:42]  * cjwatson grabs the image to look in more detail
[09:42] <infinity> But I did the seed change at more or less the optimal time (sure, there's a window for a publisher cycle there, or so)
[09:43] <cjwatson> the build is around the time when you *might* have got unlucky, but I'll check
[09:43] <psivaa> there seems to be a new kernel yesterday 3.8.0-19
[09:43] <cjwatson> yeah, I know
[09:43] <cjwatson> I'll look into it
[09:44] <psivaa> cjwatson: ok thank you
[09:44] <cjwatson> psivaa: can I have a link to the full log?
[09:45] <psivaa> cjwatson: i'm trying to load that in the public instance which has not still loaded, ill copy and paste the full log from the private jenkins
[09:45] <infinity> Maybe if we mangle when cdimage dailies build, we can just disallow migration of d-i/linux during suboptimal windows. :P
[09:45] <cjwatson> I have lab access, so a private jenkins link would be fine
[09:46] <infinity> Or maybe my hackish solution to get kernel ABIs completely out of the seeds would solve all of this.
[09:46] <psivaa> cjwatson: http://pastebin.ubuntu.com/5721108/
[09:46] <infinity> I'll have to look at landing that early in S.
[09:47] <cjwatson> hmm, that's d-i with -18 and -18 is on the images.
[09:47] <cjwatson> Apr 19 08:19:23 main-menu[1734]: (process:13782): libkmod: kmod_lookup_alias_from_builtin_file:
[09:47] <cjwatson> Apr 19 08:19:23 main-menu[1734]: (process:13782): could not open builtin file '/lib/modules/3.8.0-18-generic/modules.builtin.bin'
[09:47] <cjwatson> is that a recent kmod change?
[09:48] <infinity> I did upload a new kmod, but that seems to be a red herring, no?
[09:48]  * xnox thought i was fixing builtin file opening.... and it was mostly harmless before?!
[09:48] <infinity> Apr 19 08:19:23 main-menu[1734]: (process:13782): unknown udeb squashfs-modules
[09:48] <infinity> Apr 19 08:19:23 main-menu[1734]: (process:13782): FATAL: Module squashfs not found.
[09:48] <infinity> Those seem to be the more interesting lines.
[09:49] <cjwatson> ah, yeah, that's package-level of course
[09:49] <cjwatson> ok, I'll have to actually try the image and see what's going on there
[09:50] <infinity> Could this just be that the test was run after I NBSed out squashfs-modules-18?
[09:50] <infinity> Though, I assume that should be on the CD, so nevermind.
[09:50] <cjwatson> it may well have been, because squashfs-modules sure isn't on the image
[09:51] <cjwatson> this is odd because various other -modules are
[09:51] <cjwatson> (which means that the sanity check in debian-cd didn't fire)
[09:52] <infinity> Seems like a bunch of them aren't on the image.
[09:52] <cjwatson> aha, and the image build postdated the seed change
[09:52] <cjwatson> ! Allowing d-i kernel versions: ['3.8.0-19-generic']
[09:52] <ubot2> cjwatson: I am only a bot, please don't think I'm intelligent :)
[09:52] <cjwatson> ! Pruned squashfs-modules-3.8.0-18-generic-di from installer
[09:52] <ubot2> cjwatson: I am only a bot, please don't think I'm intelligent :)
[09:52] <cjwatson> oh shut up ubot2
[09:52] <infinity> So, just poor timing.
[09:53] <infinity> Mystery solved.
[09:53] <cjwatson> but then things like
[09:53] <cjwatson> * Chose crypto-modules-3.8.0-18-generic-di out of crypto-modules to satisfy netcfg
[09:53] <cjwatson> and indeed this is probably why:
[09:53] <cjwatson> [09:53] <cjwatson> Fri Apr 19 07:07:54 UTC 2013
[09:53] <infinity> Right, so all the modules that made it are there because of transient deps, not direct seeds.
[09:53] <cjwatson> so it was building alongside something else and hence the mirror was a bit staler than it should have been
[09:54] <cjwatson> cdimage's parallel build support isn't perhaps as absolutely perfect as it should be for this (though it's not clear that it can be)
[09:54] <cjwatson> So the fix is just to respin the ISO part.  I'll do that now
[09:54] <infinity> Is there no kernel in the squashfs for server?
[09:55] <infinity> Ahh, guess not.
[09:55] <cjwatson> nope
[11:05] <cjwatson> psivaa: should be better now?
[11:09] <psivaa> cjwatson: our cron jobs have not yet picked up the new set. Will let you know once they run.
[11:10] <psivaa> cjwatson: thanks for the quick fix though :)
[11:12] <psivaa> cjwatson: The desktop media-info files still say Alpha. I know that does not have any user impact, but is there a plan to change it? Or Is it that todays desktop images wont be the RC?
[11:13] <cjwatson> psivaa: I already changed that earlier today in the code
[11:13] <cjwatson> those desktop images can't be RC
[11:13] <psivaa> cjwatson: ack
[13:45] <xnox> ev: well does it matter who files the RT for signing wubi? =) my RTs usually get stuck forever.... Yours are getting done quicker ;-)
[13:46] <ev> :) you just need to make friends with people in IS/webops
[13:46] <ev> on it
[13:47] <xnox> ev: thanks.
[13:47]  * xnox just makes friends with you ;-)
[13:48] <ev> xnox: ha! :) I don't think the transitive property applies to RT
[13:48] <ev> oh wait, it just did
[13:48]  * xnox hides
[13:51] <ev> RT 60951
[13:56] <xnox> ev: No permission to view ticket  =(
[13:56] <ev> strange
[13:56] <xnox> maybe after it's trianged in correct queues?!
[13:56] <ev> yeah, probs
[13:57] <xnox> anyway added to my short list of RTs I am waiting on.
[14:02] <ev> xnox: if you're blocked on RTs, Steve can raise the priority of them and mention them in his catch up call with IS
[14:02] <cjwatson> yeah, doit, he wants to have something to talk about there :)
[14:02] <ev> xnox: it also helps to know whats in front of you: https://portal.admin.canonical.com/ruins?team=losa
[14:03] <xnox> ev: well, _I_ am not blocked on them. They are just fixes that affect the users of our services: manpages.ubuntu.com, geoip-lookup.ubuntu.com, wubi release.
[14:04] <ev> geoip-lookup is relatively important, I would think
[14:04] <ev> definitely worth mentioning to Steve
[14:05] <xnox> well geoip is #15 with size estimate XS =) (i hope that's ExtraSmall and not ExtrodinarySophisticated)
[14:06] <xnox> and manpages got reopened and are not up on the board yet.
[14:07] <xnox> any opinions on bug 1170150
[14:07] <ubot2> Launchpad bug 1170150 in grub2 (Ubuntu) "vmlinuz/initrd.img symlinks do not point to signed versions on kernel updates of secure boot UEFI machines" [Medium,Confirmed] https://launchpad.net/bugs/1170150
[14:07] <xnox> ?
[14:11] <cjwatson> how is that a grub2 bug?
[14:11] <cjwatson> it doesn't manage the symlinks
[14:11] <xnox> cjwatson: what does manage symlinks? linux-kernel?
[14:11]  * cjwatson reassigns to linux
[14:12] <cjwatson> -> not our problem :)
[14:12] <xnox> love it =)
[14:12] <cjwatson> (also not a release-critical problem or anything since the symlinks are only ever used for the sort of manual use case the reporter suggests)
[14:19] <xnox> ev: when you will be state side would be able to poke Keybuk about doing a libnih release? or e.g. handing the project over to ~upstart-devel team? https://code.launchpad.net/libnih/+activereviews shows the amount of fixes that are in ubuntu but not upstream, and there hasn't been a bugfix release with those.
[14:19] <xnox> we have a few people on RPM-based distros asking for a tarball release with all of those fixes.
[14:20] <xnox> ev: or is it something you don't talk with Keybuk about? =))))
[14:21] <ev> texted him what you said
[14:23] <xnox> ev: thanks.
[14:24] <ev> fingers crossed that it's just something he can quickly cover off on the google bus
[14:24] <xnox> haha.
[14:48] <mpt> xnox, what do you think of the jumpy "Keyboard layout" step?
[14:49] <mpt> http://goo.gl/YwIcT
[14:51] <xnox> mpt: I am currently staring at the spinning logo around the image.
[14:51] <xnox> =)))) one moment please.
[14:55] <xnox> mpt: description sounds ok. But how does one /change/ layouts any any step? (or are we simply not support that like we currently do). E.g. what if I want English(US) everywhere but at the Name field I got a feeling to type "Дмитрий Ледков"? aka setting up a secondary layout?
[14:55] <xnox> or should we always setup english as a secondary layout and say " you can change layout above, or by pressing Control-x Alt-c Alt-butterfly
[14:56] <cjwatson> If you set up a non-Latin layout in console-setup then it is always true that you can press Alt+Shift to toggle to English
[14:56] <mpt> xnox, same as normal, using the text entry menu in the menu bar
[14:56] <cjwatson> (IIRC)
[14:57] <xnox> mpt: ack.
[14:57] <mpt> Which ... actually isn't mentioned at the moment
[14:57] <xnox> cjwatson: I had no idea, and I don't think we tell users that at the keyboard step do we?
[14:57] <cjwatson> I don't think we do
[14:57] <mpt> fixed
[14:57] <cjwatson> But we might as well tell people rather than inventing another set of keys :)
[14:58] <cjwatson> I think we may have told people at one point and it got lost in a redesign
[14:58] <xnox> mpt: is your google doc meant to have a spinner animation as the first figure under Keyboard layout? cause that's what I see here.
[14:58] <mpt> xnox, that happened when I moved it from one part of the document to another. I'm trying to pluck the image out of an older revision.
[14:58]  * xnox thinks "interation" is a better word than "redesign" as really everything is constantly "redesigned" =)))))
[14:59] <xnox> s/interation/iteration/
[15:00] <mpt> Fixed!
[15:00] <cjwatson> Well, I was specifically thinking about before the maverick-redesign branch, but I may well be mistaken
[15:01] <mpt> I've been doing more or less of the design since Ubiquity started, and this is the first I've heard of Alt Shift :-)
[15:03] <xnox> cjwatson: Alt Shift launches Unity HUD for me to search/execute global-menu items
[15:03] <xnox> or if done too quick, does nothing.
[15:05] <xnox> right - I reset to default readd Russian layout and the "key combination to change layouts" has nothing selected.
[15:06]  * xnox goes to file a bug.
[15:07] <cjwatson> Bah, I guess the Unity folks didn't know about it either ...
[15:08] <xnox> cjwatson: askubuntu brings up 2 year old questions with total of 20 000 views on approx. "why alt+shift doesn't change keyboard layout"
[15:09] <xnox> enabling alt-shift does work well enough with HUD/Dash/Apps
[15:09] <xnox> so it's just that shortcut is not enabled by default at all.
[15:12] <cjwatson> It's only enabled by default if you installed with a non-Latin layout
[15:12] <cjwatson> Or used to be anyway ...
[15:20] <xnox> Русский is non-latin =) i will do a test install at the weekend to test this.
[15:21] <cjwatson> Should be, yeah ...
[15:51] <ev> xnox: jacekn is signing wubi now
[16:29] <ev> xnox: signed wubi is in place
[16:41] <xnox> ev: awesome, what's next to "release it" ? I guess next raring image build will simply pick it up?
[16:41] <xnox> and precise daily as well?
[16:41] <ev> correct
[16:41] <xnox> what about just wubi.exe downloads from ubuntu.com?
[16:42] <xnox> would those just work after the image build?
[16:42] <cjwatson> The web team usually make that be a redirect to the one we publish on releases.ubuntu.com
[16:42] <cjwatson> Or a mirror of it
[16:43] <xnox> cjwatson: yeahp, link from ubuntu.com for precise wubi goes to: http://www.mirrorservice.org/sites/releases.ubuntu.com//precise/wubi.exe
[16:43] <xnox> cjwatson: so would you just republish precise wubi there? or do you want me to test the know signed wubi.exe first?
[16:44] <cjwatson> Usually done at the next point release
[16:44] <cjwatson> But if it's a fix for 12.04.2 then we could republish
[16:44] <cjwatson> Rather have it tested first though
[16:45] <xnox> cjwatson: it's a fix for 12.04.2, so we didn't release any wubi with 12.04.2 but we should have, due to kernel name change to -> *.efi
[16:45] <xnox> cjwatson: ok will test as per precise-daily iso tracker wubi test cases & will report results there, such that it's documented.
[16:48] <cjwatson> ah yes, that
[21:32] <mattrae_> hi, during installation it says it will take 53 min to download language packs. i see they are downloading at ~30KB/s not so fast. ive noticed this a couple times recently
[21:35] <mattrae_> this is for 12.04.2 desktop
[21:36] <mattrae_> wondering if anybody else has noticed that downloading the language packs is slow
[22:29] <cjwatson> mattrae_: not something we can really do much about here, I'm afraid ...
[22:29] <cjwatson> I guess the mirror for your country is suboptimal for you or something


[16:38] <ChmEarl> missing amd64 versions of udev, libudev1 (255.4*)
[16:39] <ChmEarl> in noble, this is stopping installs
[16:41] <schopin> ChmEarl: Please see the communication around xz-utils on Discourse. The archive is basically broken right now, we're working to fix it.
[16:46] <quidnunc> Maybe topic should reference the xz problem
[16:54]  * ogra_ was about to suggest that, but then noticed how long it already is ...
[21:16] <webchat78> Hi.  I would like ask about the latest status of Noble deb rebuilds due to 5.6 xz backout ?
[21:17] <BtbN> iirc noble never was on 5.6.x
[21:18] <webchat78> Is there expected time to complete the rebuilds.  GNOME and LXQT desktops are functional but KDE desktop does not update due to missing dependies.
[21:19] <webchat78> I read from Ubuntu employee devs 5.6 xv build was in proposed Noble ?
[21:20] <webchat78> My reference is https://discourse.ubuntu.com/t/whats-happening-in-noble-repositories/43729/7
[21:22] <webchat78> and below ...."the compromised liblzma and xz-utils were present in the build environment of every amd64 package built since February 26. "
[21:23] <webchat78> Anyway I wanted to know if there is expected time to complete the rebuilds so I can plan out when I will be doing my test machine updates.
[21:26] <BtbN> To me that sounds like they were installed on the build hosts
[21:31] <webchat78> OK so 5.6 was never released in the Noble deb/snap packages but the servers for packaging and compiling had 5.6 xz
[21:34] <ChmEarl> cheers, udev 255.4* is in amd64 tree
[21:36] <ChmEarl> my test install passed
[21:38] <webchat78> Just curious if xz compression is the default compression for any tools with Ubuntu ?  kernel/modules/firmware/fwupd  ?


[01:26] <cjohnston> Amoz: bug #952950 and bug #749316 should be pretty easy to start with
[19:49] <imbrandon> cjohnston: sorry last day or so has been nuts round here preping for drupalcon monday, but i'll get that stuff pushed sometime this early eveing
[19:49] <imbrandon> cjohnston: sorry to hold u up if i am
[19:51] <cjohnston> ok