[09:07] <gnuoy`> Tribaal, I have a more involved ch mp ( https://code.launchpad.net/~gnuoy/charm-helpers/hugepages/+merge/268214 ) if you have a sec that would be great but I understand if you don't :)
[09:34] <Geetha> hi
[13:22] <stub> marcoceppi: you dropped
[13:35] <aisrael> lazyPower: http://www.fastcompany.com/3027907/what-engineers-at-facebook-pinterest-snapchat-airbnb-and-spotify-listen-to-while-coding
[13:35] <lazyPower> haha the first playlist listed is a bunch o trance
[13:35] <lazyPower> niiiice
[13:36] <lazyPower> dece find, thanks aisrael
[13:36] <aisrael> lazyPower: my pleasure!
[14:51] <GS_> Hi, I am trying to deploy mysql charm using "juju deploy mysql" command on ubuntu ppc64le platform, start hook is failing with exit status 1..Can you any one please help me out on this?
[15:05] <GS_> Hi, I am trying to install mysql on ubuntu ppc64le platform using "juju deploy mysql" command, but start hook is failing. Can any one please help me out on this?
[15:35] <GS_> Hi, I am trying to install mysql on ubuntu ppc64le platform usig "juju deploy mysql" command, but start hook is failing with exit status 1. And It is working fine on ubuntu x_86 platform.
[15:36] <apuimedo> lazyPower: jamespag`: any idea why `juju ssh` to lxc container is not working
[15:36] <apuimedo> and also I can't ping connect to openstack servers running on those machines
[15:39] <GS_> Can any one help me out on this? why start hook is failing in ppc64le ?
[15:44] <ddellav> GS_, when you run juju debug-log what error messages do you see?
[15:48] <GS_> 2015-08-18 08:41:44 INFO config-changed Processing triggers for ureadahead (0.100.0-16) ... 2015-08-18 08:41:44 INFO config-changed Setting up mysql-server (5.5.44-0ubuntu<IP_ADDRESS>) ... 2015-08-18 08:41:45 INFO juju-log dataset size in bytes:<PHONE_NUMBER> 2015-08-18 08:41:46 INFO config-changed mysql stop/waiting 2015-08-18 08:41:49 INFO config-changed start: Job failed to start 2015-08-18 08:41:49 INFO juju-log Restart failed, trying again
[15:49] <GS_> 2015-08-18 08:41:49 INFO config-changed stop: Job has already been stopped: mysql 2015-08-18 08:42:19 INFO config-changed mysql start/running 2015-08-18 08:42:20 INFO start mysql stop/waiting 2015-08-18 08:42:22 INFO start start: Job failed to start 2015-08-18 08:42:22 ERROR juju.worker.uniter.operation runhook.go:103 hook "start" failed: exit status 1
[15:50] <ddellav> GS_, try: juju ssh mysql/0 that should get you onto the container with mysql installed. Then you can debug mysql directly. It looks like it didn't like some config options and couldn't start
[15:50] <n3m8tz> Hi
[15:50] <ddellav> i'd check /var/log/mysql or wherever the logs are on the container (it
[15:50] <ddellav> (it'll be in the my.cnf)
[15:58] <GS_> 150818  4:42:22 InnoDB: Completed initialization of buffer pool 150818  4:42:22 InnoDB: Fatal error: cannot allocate memory for the buffer pool 150818  4:42:22 [ERROR] Plugin 'InnoDB' init function returned error. 150818  4:42:22 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 150818  4:42:22 [ERROR] Unknown/unsupported storage engine: InnoDB 150818  4:42:22 [ERROR] Aborting
[15:59] <lazyPower> apuimedo: in a charm school will be with you shortly
[16:00] <apuimedo> ok, thanks
[16:00] <rick_h_> GS_: this looks like the defaults issue that eco saw withthe memory usage and the default.
[16:00] <rick_h_> jcastro: have a link handy? ^
[16:00] <rick_h_> aisrael: I think you were poking at it as well? ^
[16:01] <rick_h_> GS_: see https://bugs.launchpad.net/charms/+source/mysql/+bug/1373862 if that matches?
[16:01] <mup> Bug #1373862: MySQL doesn't deploy due to oversized dataset <mysql (Juju Charms Collection):Fix Committed by marcoceppi> <https://launchpad.net/bugs/1373862>
[16:01] <aisrael> oh yes.
[16:01] <rick_h_> GS_: so you might need to deploy with a different config value to get that going.
[16:01] <aisrael> When I'm running locally, I: juju set mysql dataset-size='256M'
[16:03] <aisrael> GS_: If you do that immediately after deploy, the charm should work.
[16:04] <GS_> Thank you all...I will try out this.
[16:04] <ddellav> :)
[16:49] <ejat> anyone can help me with this error : http://paste.ubuntu.com/12119236/
[16:54] <lazyPower> ejat: what substrate, charm, juju version, ubuntu version is this?
[16:54] <ejat> lazyPower : im trying the openstack-install
[16:54] <ejat> vivid
[16:57] <lazyPower> ejat: openstack-install as in autopilot from landscape?
[16:58] <ejat> yups ..
[16:58] <ejat> lazyPower : the team in #ubuntu-solution helping me now .. thanks
[16:58] <lazyPower> allright, if you need anything feel free to ping back :)
[17:20] <jeand> hi all
[17:20] <jeand> I pushed a new charm to my namespace on launchpad
[17:20] <jeand> http://bazaar.launchpad.net/~jean-deruelle/charms/trusty/mobicents-restcomm-charm/trunk/files
[17:21] <jeand> how long does it take to be indexed and available on the charm store at https://jujucharms.com/q/restcomm?series=trusty&type=charm ?
[17:21] <rick_h_> jeand: it takes 1-2 hours atm. We've got two systems (legacy and modern) than have to be kept in sync so one waits for the other to be ready
[17:22] <jeand> Thanks rick_h_ for the information
[17:22] <jeand> another thing
[17:23] <jeand> I submitted a bug
[17:23] <jeand> to have it officially in the charm store
[17:23] <jeand> https://bugs.launchpad.net/charms/+bug/1473509
[17:23] <mup> Bug #1473509: Mobicents RestComm Juju Charm <Juju Charms Collection:New> <https://launchpad.net/bugs/1473509>
[17:23] <jeand> how long does it usually takes to get a review ?
[17:23] <rick_h_> jeand: hmm, so there's a process for this. I think you have to invite or assign the charmers team to it.
[17:23]  * rick_h_ looks up the docs around that
[17:24] <jeand> it seems I can't assign it to anyone else than me
[17:24] <jeand> "You may only assign yourself because you are not affiliated with this project and do not have any team memberships."
[17:24] <rick_h_> jeand: https://jujucharms.com/docs/stable/authors-charm-store#recommended-charms
[17:25] <rick_h_> not assign but subscribe it looks like per the docs
[17:27] <jeand> Thanks rick_h_ I should have RTFM better
[17:28] <rick_h_> jeand: looks like charm proof doesn't like your yaml for the tags either atm
[17:28] <rick_h_> jeand: it throws an error, it should be more like https://api.jujucharms.com/charmstore/v4/trusty/juju-gui-38/archive/metadata.yaml possibly
[17:28] <rick_h_> or I've got a really old charm-tools (/me checks that next)
[17:29] <jeand> rick_h_, when I run juju charm proof on my side it doesn't complain
[17:29] <jeand> juju --version
[17:29] <jeand> 1.24.4-trusty-amd64
[17:31] <aisrael> What's `charm version` say?
[17:32] <jeand> charm version
[17:32] <jeand> charm-tools 1.5.1
[17:32] <rick_h_> jeand: yea, fresh install here and no PPA so looks like I've got a really old charm-tools of 1.0.0 :)
[17:32] <rick_h_> jeand: ok, so yea follow the process for the review queue, I'm not sure what the current times are on that atm though
[17:33] <jeand> ok cool
[17:33] <jeand> thanks for the help here
[17:33] <rick_h_> np, good luck!
[17:34] <jeand> looks like it's present on the charm store now !
[17:34] <jeand> https://jujucharms.com/u/jean-deruelle/mobicents-restcomm-charm/trusty/0
[17:34] <jeand> Thanks !
[17:34] <rick_h_> jeand: very cool
[17:35] <rick_h_> jeand: thanks for your patience. Once we kill off the old system we'll be making it a lot faster.
[17:35] <aisrael> jeand: Your charm should pop up here within a couple hours: http://review.juju.solutions/
[17:35] <aisrael> There's a bit of a backlog we're working through, unfortunately.
[17:37] <jeand> no worries, thanks for the notice
[17:37] <jeand> I'm testing a tentative bundle in the meanwhile
[17:46] <coreycb> beisner, charm-helpers have been synced to openstack next charms
[17:49] <beisner> coreycb, ok thanks.  fyi, fired off a trusty-liberty-proposed next deploy to see how we fair.
[17:59] <lazyPower> mbruzek: do you have a spare cycle? i need a hot review on this for OIL - https://github.com/whitmo/etcd-charm/pull/17
[18:02] <skylerberg> Is there a way to run amulet tests with a local charm? I want to specify a repository with a path, but I haven't seen anything besides the default resolver that checks the charm store when I use add.
[18:03] <lazyPower> export JUJU_REPOSITORY=path/to/charm/repo
[18:03] <lazyPower> ensure the amulet test doesnt' specify CS:<series> and isntead just declares the service
[18:03] <lazyPower> for example if you're testing the charm "foo"
[18:03] <lazyPower> amulet.deploy("foo")
[18:04] <lazyPower> it should auto-pick the local copy of the charm to deploy
[18:04] <skylerberg> lazyPower: Can I mix and match? I want to use some charms from the store and then my charm locally.
[18:04] <lazyPower> well, amulet should only be deploying the local charm thats under load
[18:04] <lazyPower> if you need multiple
[18:04] <lazyPower> use the local:series/charm directive
[18:04] <lazyPower> and make sure when you commit, its using the proper resource locations that are not local:
[18:04] <lazyPower> as that will just confuse CI and things will blow up on reporting
[18:05] <lazyPower> alai:  https://github.com/whitmo/etcd-charm/pull/17 - could use your input on this
[18:06] <alai> lazyPower, cool i'll take a look
[18:06] <skylerberg> lazyPower: Thanks for the help, that should get me going on writing these tests.
[18:12] <alai> lazyPower, +1 thanks for a quick patch
[18:28] <beisner> wolsen, gnuoy`, coreycb - fyi - in resuming the rmq edge issues @ vivid-kilo, got the 2nd of two bugs filed and I'm calling the VK test disabled-ufn:
[18:28] <lazyPower> apuimedo: i understand you're having issues with LXC on yoru cloud?
[18:29] <lazyPower> which cloud provider is this?
[18:29] <lazyPower> and how are the services deployed?
[18:29] <beisner> wolsen, gnuoy`, coreycb :  bug 1486177
[18:29] <mup> Bug #1486177: vivid-kilo 3-node native cluster race:  cluster-relation-changed Error: unable to connect to nodes ['rabbit@juju-X-machine-N']: nodedown <amulet> <openstack> <uosci> <rabbitmq-server (Juju Charms Collection):New> <https://launchpad.net/bugs/1486177>
[18:29] <apuimedo> some OSt
[18:29] <apuimedo> but it's the same I had with DO
[18:29] <beisner> wolsen, gnuoy`, coreycb :  bug 1485722
[18:29] <mup> Bug #1485722: rmq on >= vivid has mnesia (no data dir) <amulet> <openstack> <uosci> <nrpe (Juju Charms Collection):New> <rabbitmq-server (Juju Charms Collection):New> <https://launchpad.net/bugs/1485722>
[18:29] <apuimedo> I can't connect to lxc containers
[18:29] <apuimedo> except from the instance they run on
[18:30] <apuimedo> my main suspect is the arp filtering that cloud providers usually do
[18:30] <beisner> wolsen, gnuoy`, coreycb - tldr:  half the time, one unit fails to cluster, and when all 3 do cluster ok, a separate blocker exists.
[18:32] <lazyPower> apuimedo: this is the host only networking exception
[18:32] <lazyPower> which version of juju? i was under the impression 1.24 removed this limitation, but i may be wrong
[18:32] <lazyPower> let me fetch the guide that i did to fix this w/ overlay networking
[18:32] <apuimedo> 1.24.4-trusty-amd64
[18:32] <lazyPower> http://blog.dasroot.net/container-networking-with-flannel.html
[18:33] <lazyPower> yeah it seems like the networking only works on certain substrates (aws, and openstack)
[18:33] <apuimedo> I'm using OpenStack
[18:33] <lazyPower> weird, i'll have to re-ping dimiter on it then
[18:34] <lazyPower> its quite possible i am misinformed
[18:34] <lazyPower> There are bolt on services you can use to work around this
[18:34] <lazyPower> the problem is the LXC containers that are being spun up on the lost are 10.0.3.x addressing, and the juju state server has no means to communicate with them
[18:34] <lazyPower> networking addons like the fan, calico, flannel, et-al are designed to offer an SDN approach to fixing this
[18:35] <apuimedo> the juju state server works
[18:35] <lazyPower> but this also requires the LXC containers to be reconfigured to attach to that networking bridge that the state server can connect to
[18:35] <apuimedo> the relations are established
[18:35] <lazyPower> so, you can reach the LXC container based service, from the state server
[18:35] <lazyPower> but not when you juju ssh <service>/<unit> ?
[18:35] <apuimedo> I think it is most likely a matter of the undercloud having a too strict security group
[18:35] <apuimedo> yeah, juju ssh does not work
[18:35] <lazyPower> thats a bug
[18:36] <lazyPower> do you mind filing it and linking me? i'd like to track this and reference it when i poke dimiter about it
[18:36] <apuimedo> ok ;-)
[18:36] <lazyPower> we'll want the output from juju status,  the service attempting to connect to via juju ssh, any verbose debug logging, and which cloud provider if applicable
[18:38] <apuimedo> ok
[18:45] <lazyPower> alai: fix is upstream in ~kubernetes namespace, open review item here - https://code.launchpad.net/~kubernetes/charms/trusty/etcd/trunk/+merge/268373
[18:45] <lazyPower> which is for the charm store copy in ~charmers namespace.
[18:54] <alai> cool... testing it now
[19:26] <marcoceppi> rbasak: you around? I have a packaging question
[19:52] <apuimedo> lazyPower: from what I see in my machines
[19:53] <apuimedo> there's only eth0 that has the "public ip" and lxcbr0 that gets a <IP_ADDRESS>/24
[19:53] <apuimedo> but that has no link device
[19:53] <apuimedo> only veths to the lxc containers
[19:54] <apuimedo> I can't see how the different lxc containers could be able to talk to each other
[19:54] <lazyPower> apuimedo: correct
[19:54] <lazyPower> there's no cross host networking by default in juju w/ those containers
[19:54] <lazyPower> this is why SDN as a work around exists today
[19:54] <lazyPower> and juju is slowly growing support for cross-host networking natively w/ the juju networking modules.
[19:54] <apuimedo> lazyPower: so I would have to run flannel for that?
[19:54] <apuimedo> which is the simplest solution?
[19:54] <lazyPower> flannel, calico, the fan,  just to name a few that we have charms for.
[19:54] <apuimedo> fan?
[19:55] <lazyPower> https://insights.ubuntu.com/2015/06/22/fan-networking/
[19:56] <lazyPower> i use flannel quite a bit because it works cross host over an encrypted ip tunnel. its quite slow, requires ETCD to work/ do coordination, but it gets the job done.
[20:11] <apuimedo> lazyPower: is there one for the flannel integration?
[20:11] <apuimedo> article, I mean
[20:11] <lazyPower> apuimedo: the article covers the bases of how to properly get hosts talking
[20:11] <lazyPower> it requires deploying the flannel charm first, then deploy --to lxc: on that host
[20:11] <cholcombe> lazyPower, do you have RSI in your hands?  You seem to type more than anyone i've ever seen :)
[20:12] <lazyPower> cholcombe: Richardson Space Industries? nah... it would be cool if i had star citizen in my hands :D
[20:12] <cholcombe> lol
[20:12] <cholcombe> no repetitive stress injury
[20:12] <lazyPower> well, to a degree, yeah
[20:12] <lazyPower> my hands hurt on a regular basis
[20:12] <lazyPower> you'll see me massaging my hands in hangouts if you're looking
[20:12] <cholcombe> yeah
[20:13] <cholcombe> seems to be a common problem with engineers
[20:13] <lazyPower> years of being a keyboard cowboy i suppose takes its toll
[20:13] <lazyPower> some day we'll get hazard pay for it
[20:13] <cholcombe> yep
[20:13] <cholcombe> haha i wish
[20:14] <lazyPower> it was terrible cholcombe, there were cheese cakes, pizzas and beers everywhere. Our hands were cramping and we couldn't even hold on to any of the goodies!
[20:14] <cholcombe> hahah
[20:14] <cholcombe> lazyPower, well the joints in my hands are starting to sting.  i've been wondering what others are doing to alleviate it
[20:15] <cholcombe> lazyPower, i didn't mean to side track ya :)
[20:15] <lazyPower> all good man, i'm on a roll over here. running support and hacking on kubes
[20:16] <cholcombe> nice!
[20:47] <skylerberg> Is it standard practice to upload partially complete juju charms to our personal namespaces or should I not do that until I think it would be usable by others?
[20:48] <skylerberg> I am not sure if I am supposed to use that as version control or as a publishing platform.
[21:28] <hazmat> skylerberg: publishing not vcs
[21:28] <hazmat> skylerberg: vcs in git(hub) ;-)
[21:29] <hazmat> lazyPower: plus vs fan, it support aws and gce native backends no ip in ip
[21:29] <hazmat> lazyPower: what's the state of the art on monitoring
[21:29] <lazyPower> hazmat: in the jujuverse?
[21:32] <lazyPower> hazmat: i'm assuming thats what you're asking for - we haven't had extra cycles to devote to it that i'm aware of. the community may be working on additional componentry like promethius or carbon.  The question is rather contextless at this point.
[21:33] <hazmat> lazyPower: fair enough, jujuverse.. best charms for monitoring for context.. say big data
[21:35] <lazyPower> hazmat: we recently published to the mailing list a rather large story about syslog analytics
[21:35] <lazyPower> including bundle
[21:35] <hazmat> oh.. cool.
[21:36] <lazyPower> thats state of the art w/ big data and monitoring + some interesting ganglia metrics coming
[21:36]  * hazmat trawls archives
[21:36] <lazyPower> as it has native integration with the big data components
[22:34] <skylerberg> exit
[22:34] <skylerberg> oops, lol
[22:37] <marcoceppi> o/ skylerberg thanks for the contributions so far
[22:40] <skylerberg> marcoceppi: No prob. And thank y'all for being really responsive whenever I run into any issues.
[23:26] <plars> wget: unable to resolve host address ''ubuntu-14.04-server-cloudimg-amd64-root.tar.gz'
[23:26] <plars> getting this when trying to deploy things to lxc under maas
[23:26] <plars> here's a more complete log, any ideas? http://paste.ubuntu.com/12121232/
[23:36] <skylerberg> In amulet I cannot find a way to relate a service that is deployed locally. The problem is that the service name is "local:trusty/cinder-tintri". Then when I try to add the relation I have to provide a string like "local:trusty/cinder-tintri:storage-backend". The extra colon then confuses the relate function.
[23:40] <marcoceppi> skylerberg: the "local:trusty/cinder-tintri" is the name of the charm, the service is just "cinder-tintri"
[23:40] <marcoceppi> so, it's just cinder-tintri:storage-backend
[23:41] <marcoceppi> s/name/url of the charm
[23:45] <skylerberg> marcoceppi: If I try that I get a ValueError on deployer.py:261 saying that the service is not deployed. I think the whole "local:..." string is being stored as the name of the deployed charm inside amulet.
[23:45] <marcoceppi> skylerberg: can you share your amulet test file?
[23:46] <skylerberg> yeah, just a sec
[23:46] <marcoceppi> something like gist or paste.ubuntu.com should suffice
[23:47] <skylerberg> http://paste.ubuntu.com/12121295/
[23:48] <marcoceppi> skylerberg: ah, that's why, don't call the CINDER_TINTRI charm "local:trusty/cinder-tintri" that should just say cinder-tintri. amulet will detect that if the test is in the charm's name that matches the deploy line to use that instead of trying to resovle a charm store address
[23:50] <marcoceppi> skylerberg: you'll also want to make sure you have amulet 1.11.0 installed, it has some fixes for testing with more recent versions of deployer/juju
[23:52] <skylerberg> marcoceppi: Changing it to just "cinder-tintri" gives me a 404 message about the charm not being found. I just checked the version and it is 1.11.0.
[23:53] <marcoceppi> skylerberg: and this test resides within the tests directory in the charm and the charm directory is named "cinder-tintri" ?
[23:54] <skylerberg> Yes, that is correct.
[23:55] <marcoceppi> skylerberg: that shouldn't be happening
[23:55] <skylerberg> If you can point me to the line where it checks if the charm name matches the directory then I should be able to insert a debugging print statement and figure out why that isn't triggering.
[23:59] <marcoceppi> skylerberg: https://github.com/juju/amulet/blob/master/amulet/charm.py#L54
[23:59] <marcoceppi> skylerberg: that's coming from https://github.com/juju/amulet/blob/master/amulet/deployer.py#L115


[06:47] <dholbach> good morning
[12:54] <bac> morning dholbach
[13:06] <dholbach> hi bac
[13:06] <bac> nothing up daniel.  just saw you'd only been talking to yourself for a few days in here.
[13:12] <dholbach> :)


[05:17] <IveBeenBit> Does anyone feel like talking me through some installation problems for 12.10?
[05:56] <histo> !details | IveBeenBit
[05:56] <ubot2> IveBeenBit: Please give us full details. For example: "I have a problem with ..., I'm running Ubuntu version .... When I try to do ..., I get the following output: ..., but I expected it to do ..."
[08:11] <duanedesign> ikonia:
[08:11] <duanedesign> oops sorry
[20:04] <JonEdney> Im planning to build a new PC, to run Ubuntu 12.10 on primarily.  I've done a lot of looking around in regards to hardware compatibility.  I'm currently looking at an Intel i5 CPU, but due to cost, I need to downgrade that.  Anyone have any exp running on some of the Pentium or Celeron processors?
[20:46] <holstein> JonEdney: you get what you pay for
[20:46] <holstein> JonEdney: if i were not going to drop some cash on some nice new hardware, i would just get something used
[20:47] <holstein> i got a dual core box for free a couple years ago and maxed out the ram
[20:47] <JonEdney> yeah thats what I was assuming, but building is new to me.
[21:23] <userubuntu> hi I have a problem when installing ubuntu, my mouse does not work, during the installation and after that It used to work previously and it does in other operative systems. I tried some workarounds but I am stuck
[21:27] <holstein> userubuntu: you can really only search around, and try different live CD's
[21:29] <userubuntu>  holstein I tried to reboot Ubuntu from a pendrive (that is how I re install it) and the mouse is not detected. Previously it was but had some problems, so I decided to reinstall the version 12.04
[21:31] <holstein> userubuntu: if its not working on the live CD, it wont work
[21:31] <holstein> userubuntu: not "out of the box" anyways
[21:32] <holstein> userubuntu: what would i do? make sure its not a hardware issue
[21:32] <holstein> if it worked for certain in a verion of ubuntu, load that live CD
[21:32] <userubuntu> holstein it is not, I checked in other computer and it used to work previously
[21:32] <holstein> check the bios, check hardware switched
[21:32] <userubuntu> (albeit with problems)
[21:32] <holstein> switches*
[21:32] <userubuntu> ok will go to bios
[21:32] <holstein> userubuntu: you'll need to entertaion that it is one of 2 things
[21:32] <holstein> hardware or software
[21:33] <holstein> if its hardware, it could be a switch, or broken hardware, or disbled
[21:33] <holstein> if its software, it could be software support for the device is lacking in linux
[21:33] <holstein> those are really all the options.. you just troubleshoot and rule them out, one at a time
[21:33] <userubuntu> how can I see if the mouse is enabled through the terminal (as I cannot really use the mouse)
[21:34] <holstein> userubuntu: it is enabled in the terminal
[21:34] <holstein> userubuntu: you dont get a mouse in a terminal
[21:34] <holstein> you didnt "disable" it in a freshly booted live CD
[21:34] <holstein> so, you dont need to troubleshoot "did i disable it"
[21:34] <holstein> you need to determine if the hardware is working
[21:35] <userubuntu> ok
[21:35] <userubuntu> will got to bios
[21:36] <holstein> go to *any* live CD that used to work with it
[21:36] <holstein> take your current OS out of the equation
[21:36] <holstein> then, if it did work with that live CD in the past, and you are *certain* of that, then its safe to assume its either disabled, or broken
[21:37] <userubuntu> ok will try this
[21:39] <userubuntu> mouse work in bios so it is safe to assume it is not a hardware issue
[21:39] <userubuntu> and somehow it is now working
[21:40] <userubuntu> this is odd, but thank you holstein for your help
[21:42] <holstein> userubuntu: cool.. then you can move on to software
[21:42] <holstein> try a live CD, and take your current OS out of the equation


[00:09] <Viper550> wait GRUB2?
[00:15] <Viper550> and are we ever going to use gfxboot on an install/
[00:15] <cody-somerville> Viper550, we're getting rid of usplash
[00:16] <cody-somerville> Viper550, We think we can boot so quickly we don't need anything like that
[00:23] <TheMuso> cody-somerville: its not going away entirely, it will be used for fsck/dm-crypt password entry.
[00:39] <cjwatson> soren,slangasek: I think livecd-rootfs actually runs in a hardy chroot for hardy CD builds, and we use the hardy version of it; however the ISO building code is central and so has to be guarded as slangasek says
[00:39] <slangasek> ah
[00:39] <slangasek> does that mean we could trim the hardy exceptions in the current version of livecd-rootfs? :)
[00:39] <cjwatson> slangasek: check with Adam, but I think so
[01:37] <Cameron> hi.. i'm trying out grub2, and managed to get it to work on jaunty, both chainload and native.  This was done using a separate hdd for /boot since my root partition is ext4 on lvm.  Now, I wish to test using /boot on my root partition.  I reconfgured /boot to be a normal folder, and ran this : grub-install /dev/sda  I received this error "error: Unknown metadata header" followed by grub-probe: error: no mapping exists for `Ubuntu
[01:37] <Cameron> -jaunty'
[01:37] <Cameron> then this Auto-detection of a filesystem module failed.  Please specify the module with the option `--modules' explicitly.
[01:38] <Cameron> cjwatson: you about ?
[01:47] <shaya> wondering if others are getting spammed like crazy by apport retracing service today on old bugs?
[01:47] <TheMuso> shaya: Yes, I am.
[01:48] <maco> aye
[01:58] <cjwatson> Cameron: about to go to bed, please do file a bug though - not many people have tried grub2 on lvm root yet (at least not in Ubuntu) and we clearly need to sort some things out
[01:59] <Cameron> cjwatson: shall do, thanks
[03:16] <Cameron> cjwatson: fyi the bug is here https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/385428
[03:17] <Cameron> thanks ubottu :)
[04:14] <AnAnt> Hello, is gdm2 available in any PPA ?
[04:14] <AnAnt> gdm 2.26 that is
[04:21] <Hobbsee> AnAnt: #launchpad for ppa questions.
[04:22] <persia> Hobbsee, Including content search?  I thought that was beyond the scope of that channel as well.
[04:22] <Hobbsee> persia: you're probaby right there.  Unless they can point him to where the search over ppas actually is
[04:23] <persia> I remember hearing about the PPA search tool recently, but I understood it to be external to LP itself.
[04:24] <nhandler> persia: You are probably thinking about http://ppa-search.appspot.com/
[04:27] <AnAnt> I thought maybe the ppl working on the new GDM were here, that's why I asked
[04:29] <persia> nhandler, Quite possibly, indeed.
[04:31] <AnAnt> yup, found it, thanks
[04:55] <poolie> hi, i'm running karmic with an intel gm965
[04:55] <poolie> in the last couple of days the screen has started sometimes going irretrievably blank
[04:56] <poolie> can anyone give me a pointer or should i just file a new bug?
[04:59] <persia> poolie, Have you experimented with the xorg-edgers repo?  It may break things more, but it may break them less.
[04:59] <poolie> yeah lifeless just suggested that
[04:59] <persia> (they don't call themselves the "Xorg Crack Pushers" for nothing.
[04:59] <poolie> it feels a bit like randomly changing things
[04:59] <poolie> i'd rather have some tea
[05:00] <persia> It *is* randomly changing things.
[05:00] <persia> But theoretically, if you have an issue, and it's fixed by the crack, that's valuable information to provide in the bug.
[05:00] <poolie> yes
[05:00] <poolie> i'll file a bug then try it
[05:02] <Hobbsee> poolie: oh yeah, i've been noticing that.  it's a pain
[05:03] <poolie> ok bug 385448
[05:03] <poolie> hello Hobbsee
[05:03] <Hobbsee> poolie: heya!
[05:08] <nixternal> come on, accept kdebindings binaries already :p
[05:09]  * nixternal needs python-kde4 to continue working
[05:12] <poolie> so there seem to be no karmic builds in
[05:12] <poolie> deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu jaunty main
[05:13] <lifeless> deb http://ppa.launchpad.net/xorg-edgers/ppa/ubuntu karmic main
[05:14] <ScottK> nixternal: I'd love to help you, but the package has mono stuff in it.
[05:14] <ScottK> ;-)
[05:14] <nixternal> lol
[05:14] <nixternal> w/o kdebindings getting in, anything with pykde will not work
[05:15] <nixternal> things such as ubiquity, gdebi, printer, and so forth
[05:15] <ScottK> nixternal: I'm looking at it for binary New now.
[05:16] <lifeless> https://edge.launchpad.net/~xorg-edgers is the one : it has the git builds that lead into what will land in ubuntu
[05:17] <ScottK> nixternal: Accepted.  You should have the binary in ~90 minutes.
[05:17]  * nixternal hugs ScottK
[05:25] <poolie> lifeless: thanks, i think that's a bit too scary atm
[05:25] <poolie> or rather, beyond the depth i want to get into this
[05:25] <poolie> at least til bryce asks
[05:31] <lifeless> poolie: so, bryce has asked somewhat generally :). But thats ok - I'm sure he will
[06:39] <pitti> Good morning
[06:39] <nixternal> and good morning to you sir
[06:39] <pitti> hey nixternal
[07:19] <\sh> moins
[07:19] <\sh> slangasek: thx...I solved it in a more sane way..."do not install menu.lst manually, but call update-grub -y, so it installs a newly created menu.lst"
[07:21] <slangasek> that would also do it
[07:22] <slangasek> "sane" - it discards any existing settings in menu.lst, so it's not usually my first recommendation
[07:23] <\sh> slangasek: the problem was during initial installation...so it doesn't have any changes :)
[07:23] <slangasek> ok
[07:27] <StevenK> Blink
[07:27] <StevenK> Where did the udev rules go ....
[07:27] <pitti> StevenK: to /lib/udev/rules.d/ ?
[07:28] <StevenK> Sigh. Nice if /etc/udev/rules.d was a symlink to that, but dpkg doesn't like that situation
[07:28] <pitti> nah, it shouldn't
[07:28] <pitti> /etc/udev/rules.d is for local customization
[07:28] <dholbach> good morning
[07:28]  * pitti hugs dholbach
[07:28]  * dholbach hugs pitti back
[07:29] <StevenK> pitti: Ah, so I can drop a rule in /etc/udev/rules.d and it will override what is in /lib/udev/rules.d for say, that particular SUBSYSTEM ?
[07:30] <pitti> StevenK: AFAIK they are executed in addition
[07:30] <maxb> same-named files override
[07:30] <maxb> or at least, that's what the manpage claims
[07:30] <pitti> "Files in /etc/udev/rules.d/ have precedence over files with
[07:30] <pitti>        the same name in /lib/udev/rules.d/."
[07:30] <pitti> right
[07:35] <\sh> unsubscribe ubuntu-devel-discuss
[07:35] <\sh> done
[08:03] <ttx> slangasek: created likewise-open5 bug 385475
[08:18] <jamesh> pitti: hi.  there was a bit more discussion about the Erlang packages that it seems you weren't CC'd on.  I've just forwarded you an email with the current status.
[08:29] <\sh> releases.ubuntu.com
[08:29] <\sh> down?
[08:31] <\sh> argl...damn telemaxx carrier
[08:32] <iulian> \sh: Seems so.  It failed to connect here as well.
[08:32] <\sh> iulian: from my home carrier (kabelBW) it works
[08:32] <iulian> Huh?  That's odd.
[08:32] <iulian> It fails to connect here.
[08:39] <\sh> iulian: which ip address do you get for releases.ubuntu.com?
[08:39] <\sh> <IP_ADDRESS> or <IP_ADDRESS> ?
[08:41] <\sh> looks like that it's a dns caching problem .. good to know that my DNS on my rooty is configured properly and not doing wile things
[08:41] <\sh> s/wile/wild/
[08:46] <iulian> \sh: releases.ubuntu.com has address <IP_ADDRESS>
[08:50] <\sh> iulian: and that's wrong..dns caching issue...
[08:50] <soren> cjwatson: Ok. Thanks for clarifying.
[08:51] <\sh> I just kicked our DNS admin to do his job
[08:56] <nixternal> pitti: re: apport - should I look at implementing the features that GTK has compred to Qt? is there a reason they aren't implemented already?
[08:57] <nixternal> also, re: apport-qt - it will be rewritten in PyKDE4 - which is what I am messing around with now
[09:03] <AnAnt> Hello, why is wine in Ubuntu different than in Debian ?
[09:03] <AnAnt> I mean that Ubuntu doesn't use Debian's wine package
[09:06] <directhex> YokoZar, customer for you
[09:06] <YokoZar> directhex: oh?
[09:06] <directhex> AnAnt, (yokozar is in a yank timezone, so best to ask when america is awake)
[09:06] <directhex> oh. erm...
[09:06] <directhex> YokoZar, AnAnt's query
[09:07] <YokoZar> AnAnt: Because our Wine package provides more integration stuff and isn't split into useless subpackages
[09:07] <AnAnt> aha, ok
[09:08] <AnAnt> YokoZar: so, will wine 1.1 be in karmic ?
[09:11] <AnAnt_> sorry, I got d/c
[09:11] <AnAnt_> YokoZar: so, will wine 1.1 be in karmic ?
[09:12] <YokoZar> AnAnt_: 1.2 might be released in the Karmic timeframe
[09:12] <YokoZar> I don't want to hold people back on 1.0 for another release
[09:12] <AnAnt_> YokoZar: do you mean, that it is either 1.0 or 1.2 ?
[09:12] <YokoZar> So i've been pushing pretty hard upstream to have 1.2 out
[09:13] <YokoZar> 1.1 are development releases that aren't regression tested
[09:13] <AnAnt_> is 1.1 an unstable release ?
[09:13] <YokoZar> Yes, very much so
[09:13] <AnAnt_> aha, ok, thanks
[09:13] <nixternal> pitti: I am heading to bed, go ahead and highlight me with a response so I can work on it when I get up and about, thanks!
[09:13] <AnAnt_> oh, yes they are in experimental ! my bad !
[09:13] <YokoZar> I may need to pick a 1.1.x version and regression test it heavily around feature freeze if it looks like wine 1.2 isn't coming out in time
[09:45] <tjaalton> asac: hey, do you have plans to upload the fix to bug 220628 to jaunty-proposed?
[09:55] <cjwatson> pitti: Am I right in thinking that valid mount options have to be hardcoded into devicekit-disks - there's no mechanism for filesystems to ship fdi files or equivalent to override that? This is prompted by http://launchpadlibrarian.net/27592171/ntfs-3g_2009.4.4-1ubuntu1.patch (attached to bug 349569) which includes the changelog entry "Don't install HAL fdi file. Mounting is done via devkit-disks now."
[09:55] <cjwatson> pitti: but the fdi file was added as a workaround because the kernel driver doesn't support locale=
[10:07] <asac> tjaalton: oh right.
[10:07] <asac> tjaalton: if you want, go ahead ;)
[10:11] <tjaalton> asac: ok :)
[10:38] <cjwatson> lamont: I don't suppose you could have a look at bug 319656 (presumably wearing your Debian hat)? I can't reproduce the problem here and don't know nmap well enough to want to guess
[10:58] <Ampelbein> cjwatson: I can reproduce the issue with nmap. I sorted out the various "not a file" errors by copying the missing scripts to /usr/share/nmap/scripts, but still get http://paste.ubuntu.com/192405/
[11:02] <cjwatson> Ampelbein: I think it's probably best if lamont deals with it anyway, since he's the Debian maintainer :)
[11:03] <Ampelbein> cjwatson: ok, just in case you (or lamont) need a "victim" to test fixes on: I'm here. ;-)
[11:28]  * cjwatson belatedly remembers that during a soft freeze is a silly time to be catching up on main sponsorship. *blush*
[11:29] <dholbach> cjwatson: do *verse sponsorship instead! :-)
[11:30] <dholbach> unfortunately there's enough to choose from
[11:30] <cjwatson> already am ;-)
[11:31] <dholbach> although we're slowly catching up
[11:31]  * dholbach hugs cjwatson
[11:58] <chrisccoulson> hey pitti / cjwatson - i just saw the comment on bug 349569
[11:58] <chrisccoulson> you had any thoughts about that yet?
[12:19] <pitti> jamesh: ah, thank you
[12:20] <pitti> nixternal: what's still missing in the qt version? It should be on feature parity now, AFAIK
[12:20] <pitti> chrisccoulson, cjwatson: looking (just returned from appointment, sorry for delay)
[12:21] <chrisccoulson> piit - no hurry. i was just wondering if you already discussed it or not
[12:21] <chrisccoulson> **pitti
[12:21] <chrisccoulson> lol
[12:22] <directhex> seb128, ping - do you think it's preferable for banshee's magnatune plugin to spawn a web browser for purchases, or take people's credit card details straight in the app? rhythmbox does both (window for downloads, web page for cd purchases)
[12:23] <seb128> directhex: hello, no real opinion on that I think both are fine, maybe better to ping mpt to get some design team advice though
[12:24] <seb128> directhex: I would tend to say that using the website in a browser we are in a known environment security wise
[12:25] <seb128> so it makes things easier
[12:25] <directhex> seb128, i agree - but it's less "integrated"
[12:25] <directhex> so damned if you do, damned if you don't
[12:26] <seb128> that's why I say "no real opinion"
[12:26] <seb128> I think both options will do
[12:26] <seb128> so whatever somebody is wanting to do
[12:29] <stgraber> pitti: hey, about the numlockx MIR, what do you mean by the two questions from comment 1 ? Didn't I answer them in the following comment (and in the MIR wikipage itself) ? or did I miss something ?
[12:37] <pitti> cjwatson: I asked on the upstream ML
[12:38] <pitti> stgraber: right, I see now that you mentioned the Xsession.d file in the MIR; are you going to look after the package then?
[12:43] <directhex> seb128, a clicky button which spawns "xdg-open https://magnatune.com/buy/choose?sku=XXXXXXXXXXX&sitePrefix=" is the easy option - assuming one can retrieve the value for XXXXXXXXXXXX somehow, without downloading & searching the full site database client-side. i've mailed magnatune to ask foir suggestions
[12:43] <directhex> looks like jamendo's api is miles better
[12:43] <seb128> ok
[12:48] <cjwatson> pitti: thanks
[13:01] <stgraber> pitti: yeah
[13:03] <\sh> cjwatson: are you interested in some theories that the udev.postinst is quite dangerous at some time? :)
[13:05] <siretart`> If I'm reading udev.postinst right, then a dpkg-reconfigure udev will instantly kill /sbin/udevadm
[13:05] <\sh> cjwatson: actually a well configured udev is available then you just do out of couriosity a dpkg-reconfigure -a -f noninteractive and /sbin/udevadm is just gone
[13:05] <siretart`> which is rather bad :-)
[13:07] <stgraber> pitti: btw, didn't I also answer this question in the reply to your comment ? (in-line)
[13:08] <pitti> stgraber: I don't see it anywhere
[13:09] <stgraber> "Oh, thanks for spotting this. I'll update that part of the MIR.
[13:09] <stgraber> I'm fine maintaining it in Ubuntu as I'll be the main user of it anyway."
[13:10] <pitti> ah, heh
[13:11] <lamont> cjwatson: I'll get a look at it this week
[13:12] <cjwatson> \sh: -> Keybuk
[13:12] <cjwatson> lamont: thanks!
[13:12] <Keybuk> \sh: why would you ever dpkg-reconfigure udev?
[13:13] <\sh> Keybuk: tbh...it is an accident of lazyness ;)
[13:13] <ogra> heh, accidential lazyness ? sounds funny
[13:13] <\sh> Keybuk: but nevertheless, if someone would call dpkg-reconfigure -a or dpkg-reconfigure udev he/she will run into this very problem and has a system which can't update any kernel/initramfs anymore
[13:14] <Keybuk> \sh: can't see a bug about it
[13:14] <\sh> Keybuk: I'll file one...
[13:14] <cjwatson> I agree that the current code looks wrong
[13:14] <ogra> accidential lazyness ;)
[13:14] <cjwatson> (although it's a corner case)
[13:14] <\sh> cjwatson: sure :)
[13:14] <Keybuk> cjwatson: any idea for a fix?
[13:15] <cjwatson> Keybuk: wrap the contents of enable_udevadm with if [ -e /sbin/udevadm.upgrade ]; then ... fi
[13:15] <Keybuk> cjwatson: seems sane
[13:15] <Keybuk> though you wouldn't want to restart udevd either
[13:15] <Keybuk> in fact
[13:15] <Keybuk> at a quick glance, none of configure is appropriate
[13:16] <cjwatson> DEBCONF_RECONFIGURE=1 is set in the environment during reconfigure, if you want to guard it
[13:16] <Keybuk> that's probably the easiest
[13:16] <\sh> hmmm...
[13:16] <Keybuk> \sh: bug #366185
[13:17] <\sh> Keybuk: bug #366185 looks just the same...
[13:17] <\sh> Keybuk: I see you just renamed it :)
[13:18] <Keybuk> yeah, just read through the bugs
[13:18] <\sh> Keybuk: thx for taking care :) do you think it's worth an -proposed/-updates upload?
[13:18] <\sh> for jaunty
[13:19] <Keybuk> I always say no until someone says otherwise ;)
[13:20] <\sh> Keybuk: I'd say yes, 2 1/2h of debugging is a lot of time..and time is money ;)
[13:20] <Keybuk> I meant someone in ubuntu-release ;)
[13:23] <\sh> Keybuk: oh I forgot that ;)
[13:29] <stgraber> pitti: thanks
[13:33] <lifeless> should evince be able to print pdf's?
[13:35] <liw> lifeless, I do it frequently
[13:36] <lifeless> ctrl-P is not working and thereis no 'print' in my evince menu...
[13:37] <lifeless> buggeration time
[13:38] <pitti> hm, I print from evince all the time
[13:38] <lifeless> It works if I adda print button to the toolbar
[13:39] <lifeless> just the hotkey and menu item are awol
[13:39] <pitti> lifeless: hm, both work for me, in jaunty and karmic
[13:39] <pitti> weird
[13:39] <lifeless> this is jaunty
[13:42] <soren> lifeless: What are you trying to print?
[13:43] <lifeless> soren: a pdf
[13:43] <soren> lifeless: Clever.
[13:43] <soren> :p
[13:43] <lifeless> that was sent to me to print out and sign
[13:43] <soren> lifeless: Is it something that is likely to be marked "don't print"?
[13:43] <soren> lifeless: Ah.
[13:43] <soren> Ok, then probably not :)
[13:43] <lifeless> soren: see above, adding a toolbar icon let me print
[13:44] <soren> lifeless: Yes, I saw. I was just trying to figure out if *that* was the bug.
[13:44] <pitti> lifeless: do you also get it on /usr/share/doc/shared-mime-info/shared-mime-info-spec.pdf ?
[13:44] <soren> Truth be told, I don't know how evince deals with "non-printable" PDF's.
[13:45] <liw> lifeless, if it is the same PDF I was sent, my evince shows a print item in the menu just fine (jaunty)
[13:45] <lifeless> pitti: same behaviour
[13:45] <lifeless> liw: from the isle?
[13:45] <lifeless> liw: if so, yes.
[13:46] <lifeless> foo
[13:46] <lifeless> E [10/Jun/2009:22:40:11 +1000] PID 20891 (/usr/lib/cups/backend/ipp) crashed on signal 6!
[13:48] <lifeless> the above however makes it hard to actually get the paper out of the print
[13:48] <lifeless> er
[13:51] <sabdfl> Setting up linux-restricted-modules-common (2.6.28-13.17) ...
[13:51] <sabdfl> update-rc.d: warning: /etc/init.d/linux-restricted-modules-common missing LSB information
[13:51] <sabdfl> update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
[13:51] <sabdfl> is that normal?
[13:52] <ogra> sabdfl, if the maintainer didnt update the initscript to newer LSB yet, yes ... its just a warning though
[13:53] <ogra> doesnt do any harm
[13:53] <sabdfl> doesn't look like something we should have in a kernel package, though
[13:53] <ogra> agreed
[13:53] <sabdfl> pgraner: ^?
[13:54] <mok0> sabdfl: ah, yes, it's missing all that header stuff
[13:55] <mok0> ... but it does use the proper lsb functions
[13:56] <mok0> Isn't the init system going to be transitioned anyways?
[13:56] <wgrant> mok0: That's been happening next release since Edgy :P
[13:57] <ogra> if Keybuk makes it in time :)
[13:57] <mok0> Heh, ok
[13:57] <mok0> That header information is supposed to give some kind of dependency... allowing stuff to be started in parallel
[13:59] <mok0> wgrant: btw, the science team is dwindling
[14:00] <cjwatson> sabdfl: bug 3055878
[14:00] <cjwatson> oops
[14:00] <mok0> wgrant: only 4 members left :-(
[14:00] <cjwatson> sabdfl: bug 305587
[14:00] <wgrant> mok0: So it seems. :(
[14:00] <sabdfl> thanks colin
[14:00] <Keybuk> ogra, mok0: upstart will still use those LSB headers
[14:00] <Keybuk> in fact, we'll probably start to rely on them
[14:00] <Keybuk> so them being missing or wrong is a bug for Ubuntu
[14:00] <mok0> Keybuk: see sabdfl's question in the scrollback
[14:00] <ogra> well, for karmic :)
[14:01] <ion_> mok0: The more important thing is that their ordering can be automated. If new package baz must start before rc2.d/S20foo and after rc2.d/S20bar, the maintainer must discuss it with two other maintainers, and if 20foo is changed to 21foo and 20bar to 19bar, *that* may have repercussions for an indefinite number of other packages. That’s why Debian is trying to transition to automatic ordering based on LSB headers.
[14:01] <ogra> in jaunty its only cosmetic ... while it will do harm in karmic
[14:01] <Keybuk> mok0: what was sabdfl's question?
[14:02] <ogra> sabdfl> update-rc.d: warning: /etc/init.d/linux-restricted-modules-common missing LSB information
 update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
 is that normal?
[14:02] <Keybuk> right, it's not normal, it's a bug
[14:02]  * Keybuk thought he covered that ;)
[14:02] <mok0> Well, back to the old drawing board :-)
[14:02] <mok0> terminal window, rather
[14:03] <Keybuk> our sysv-rc doesn't use them
[14:03] <Keybuk> but when we drop sysv-rc, we will
[14:03] <ogra> and its already drawn :)
[14:03] <mok0> bug 305587
[14:03] <Keybuk> my whiteboard appears to have a picture of a duck on it
[14:03] <Keybuk> don't ask me why
[14:06] <mok0> Keybuk: Ask Pat Robertson
[14:06] <ogra> not walt disney ?
[14:06]  * liw votes for Don Rosa
[14:07] <mok0> ogra: Pat Robertson claims that gay marriage leads to sex with ducks :-P
[14:07] <mok0> http://www.poormojo.org/pmjadaily/archives/026958.php
[14:07] <ogra> aww
[14:10] <mok0> Of course Jon Steward had a field day with that on TDS
[14:14] <directhex> yay ducks
[14:17] <Keybuk> mok0: http://andrewsullivan.theatlantic.com/the_daily_dish/2008/11/the-cosequences.html
[14:30] <mok0> Keybuk: :-D
[14:31] <ogra> asac, its back ! (klicking Keybuk's link got me broken fonts again)
[14:31] <wgrant> ogra: Broken how?
[14:32] <ogra> wgrant, http://people.ubuntu.com/~ogra/ff_fonts.png like that
[14:32] <ion_> liw: Have you had a chance to look at my comments? No hurry at all, just curious to hear whether they are even remotely sane. :-P
[14:32] <wgrant> ogra: That's probably a -intel bug.
[14:32] <wgrant> There was one filed on fd.o a while ago... let's see if I can dig it up.
[14:32] <ogra> wgrant, we werent sure yesterday ...
[14:33] <ogra> that'd be cool
[14:33] <ogra> it isnt really reproducable, just shows up after some time
[14:33] <wgrant> Right.
[14:33] <wgrant> I find it happens more when I close windows.
[14:33] <ogra> and only in FF
[14:33]  * ogra doesnt use windwos :P
[14:34] <ion_> Every time someone talks about (non-)reproducable bugs, i can’t help being reminded of the xkcd strip.
[14:35] <asac> ogra: i was quite sure yesterday that its a driver bug ;)
[14:35] <asac> file it against -intel
[14:36] <ogra> lets see if we can link it to an upstream bug right away ;)
[14:36] <ogra> if wgrant finds it
[14:36] <wgrant> ogra: I can't seem to find it :(
[14:37] <liw> ion_, nope, sorry, still digging myself out into the clear air
[14:37] <liw> ion_, try again tomorrow :)
[14:37] <ion_> :-)
[14:37] <wgrant> Fedora bug #495323 looks relevant.
[14:37] <wgrant> Seems it was a kernel bug?
[14:37] <wgrant> redhat 495323
[14:37] <wgrant> fedora #495323
[14:38] <cjwatson> (I find it sometimes copes better with URLs)
[14:39] <wgrant> https://bugzilla.redhat.com/show_bug.cgi?id=495323
[14:39]  * wgrant grumbles.
[14:40] <wgrant> Aha! It lives.
[14:40] <ogra> yeah, looks the same
[14:41] <wgrant> - Add drm-intel-set-domain-on-fault.patch to fix random gem object corruption when swapping (495323 and probably others).
[14:41] <wgrant> From their kernel changelog.
[14:41] <Sarvatt> ogra, if you want to use UXA it needs a kernel update which went upstream a few weeks ago
[14:41] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=21790
[14:41] <wgrant> Ah, that's the bug I was trying to find.
[14:42] <ogra> Sarvatt, i'm running karmic, uses UXA by default
[14:42] <Sarvatt> 2.6.30-8.9?
[14:46] <asac> pitti: slangasek: StevenK: wonder if you would want to unsubscribe ubuntu-archive from 352968 for now as there will be some traffic now that i fix the build depends up-front
[14:46] <ogra> bug 385561
[14:49] <Sarvatt> the fix is in karmic kernel 2.6.30-8.9 which is why I was asking if you were using that incase you weren't for some reason
[14:51] <ogra> oh, wait, i use -7 still ...
[14:51] <Sarvatt> if you are it could use going upstream because it didnt get fixed in your case
[14:51]  * ogra curses the update-manager behavior once again
[14:51] <Sarvatt> ahh that'd explain it
[14:52] <ogra> let me update manually
[14:53] <StevenK> asac: Done.
[15:04] <tkamppeter> pitti, hi
[15:05] <pitti> hi tkamppeter
[15:10] <tkamppeter> pitti, I have a problem with applying the CUPS changes.
[15:11] <pitti> tkamppeter: I saw your mail
[15:11] <pitti> tkamppeter: Debian didn't take the change?
[15:11] <pitti> tkamppeter: can we apply the change without the new option for now?
[15:12] <pitti> tkamppeter: so that all these regressions will be fixed in both Debian/Ubuntu
[15:12] <pitti> (I get tons of Debian bug reports as well)
[15:12] <pitti> tkamppeter: and then we can upload an Ubuntu-specific cups with the -origpagesizes option
[15:12] <pitti> tkamppeter: and sync back once Debian takes it
[15:15] <tkamppeter> pitti: Debian did not touch my bug report yet (I hope the maintainer comes around with it before our FF).
[15:16] <tkamppeter> What I have done now is to change the patch to make ./configure autodetect the presence of -origpagesizes and to build with it only if it is present.
[15:16] <pitti> tkamppeter: so if you could apply the bulk of the patch to bzr, and then just do an -ubuntu1 upload with the additional -origpagesizes patch, that would be best
[15:17] <pitti> tkamppeter: oh, great
[15:17] <pitti> that's even better
[15:18] <tkamppeter> pitti: So this means I put this bulk into the BZR and do an Ubuntu upload with a versioned Poppler build AND binary dependency in debian/contro;
[15:18] <pitti> tkamppeter: no, you can commit everything to bzr then; you don't need a versioned poppler dependency at all then
[15:18] <pitti> tkamppeter: (pdftops --help 2>&1| grep -q -- -origpagesizes ?)
[15:19] <pitti> tkamppeter: or how do you detect this?
[15:19] <tkamppeter> Yes, I check whether the help message of pdftops contains -origpagesizes.
[15:20] <pitti> cool
[15:20] <tkamppeter> But I do it at build time, so if the build server already switched to the new pdftops but the user not yet, the filter will fail.
[15:20] <pitti> tkamppeter: I have an idea how to fix this; please commit your's to bzr, I'll do the substvars magic
[15:21] <asac> anyone uses bfilter?
[15:23] <tkamppeter> pitti, OK.
[15:34] <Keybuk> WTF
[15:35] <Keybuk> my phone just declared that "a BaseBand Core Dump is in Progress"
[15:35] <liw> Keybuk, thanks
[15:35] <liw> I've been tempted by an evil phone today again, now I'm all better
[15:35] <liw> (and now I can go back to drooling for a freerunner)
[15:38] <ion_> My phone has been automatically changing its timezone to UTC+1 recently.
[15:39] <persia> As "phones" become "computers", we can only expect the quality of service to change to match the functionality.  Long live the ATT Model 500!
[16:01] <slangasek> ttx: thanks, added to https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview (which, btw, you're free to edit directly ;)
[16:02] <ttx> slangasek: will do, next time :)
[16:04] <asac> doko: classpath build deps not installable? http://paste.ubuntu.com/192655/
[16:05] <doko> dpkg: unrecoverable fatal error, aborting:
[16:05] <doko>  fork failed: Cannot allocate memory
[16:05] <doko> E: Sub-process /usr/bin/dpkg returned an error code (2)
[16:05] <doko> what does this have to do with classpath?
[16:06] <ion_> Do you have an ulimit that might have something to do with that?
[16:11] <asac> doko: err. well, the problem is that it cannot install the build-deps
[16:11] <asac> let me retry
[16:12] <doko> asac: classpath really should be updated to the 0.98 release
[16:12] <asac> doko: but you spotted it  ;)
[16:12] <ogra> must be the new java implementation of dpkg :P
[16:13] <asac> doko: well. i fix the libxul-dev depend now
[16:13] <asac> to be xulrunner-dev
[16:13] <doko> asac: not an oem task ;-p
[16:13] <asac> thats why i am doing it ;)
[16:16] <asac> so gcj conflicts now gcjdoc.
[16:16] <asac> what a mess
[16:17] <asac> err gcj-jdk conflicts gcjdoc
[16:18] <asac> lets see if moving build depend to that helps ;)
[16:22] <Aquina> hy
[16:23] <Aquina> aa-logprof and aa-genprof ask for usernames and passwords after creation or before reading logs. Unfortunately the server cannot be contacted.
[16:24] <asac> superm1: wanna upload new bluez?
[16:24] <asac> (after alpha2)
[16:24] <superm1> asac, i'm actually thinking i'm gonna sync to debian
[16:24] <mterry> slangasek: BTW, I've seen several packages in Debian that use dep5 already while I've been merging.  Might be larger use that you think
[16:24] <superm1> i've been reviewing all the delta between us
[16:24] <mterry> slangasek: (I remember you suggesting nobody uses it yet)
[16:25] <superm1> but sure, i'll either sync or upload a new version post alpha2
[16:25] <asac> superm1: ok. great. do you think pulse is up to date enough? i would like to call for testing after we updated all the pieces for testing (with the gnome-bluetooth thing)
[16:26] <superm1> asac, i'm not sure the status of that pulse bluetooth plugin, dtchen, can you comment?
[16:26] <superm1> but yeah, a call for testing would be very good
[16:26] <asac> superm1: following the bluetooth-stack spec
[16:26] <asac> superm1: right. i just think we should have all the latest pieces because things seems to be still moving - especially on pulse freont

[16:27] <asac> ok so lets check after alpha2 is out
[16:27] <superm1> ok sounds good to me
[16:28] <slangasek> mterry: no, I'm sure there are some people using it; I just think it's premature because the spec is still subject to *significant* changes before it reaches anything approaching consensus in Debian
[16:28] <mterry> slangasek: OK, well just be assured that there's dep5 love out there.  Though some were using very pre-dep5 versions and the like
[16:29] <slangasek> "pre-dep5 versions" - yeah, I don't count those
[16:29] <asac> superm1: what bluetooth hardware do you have?
[16:29] <persia> The trick to using DEP5 (or a predecessor) is to be sure to specify the *precise revision* of the page that one complies with.  Most users should expect to be non-compliant for their next upload.
[16:29] <slangasek> no one's going to write a parser to handle 300 revisions of a wiki page, chosen at random by the uploaders :P
[16:29] <mterry> slangasek: Meh.  pre-dep5 versions is just an early dep5
[16:30] <superm1> asac, i've  got a variety of dell bluetooth chips, a keyboard mouse stereo headset and mobile phone
[16:32] <persia> slangasek, That something happens to be compliant with a given URL doesn't mean it's compliant with the *goals* of the effort :)
[16:32] <slangasek> persia: that sounds like you may be violently agreeing with me
[16:33] <persia> slangasek, I think the only point of disagreement is that I don't mind if someone happens to use something in that format, and will happily review it against the revision they specify, rather than asking "Why?".
[16:33] <slangasek> oh, I don't mind if someone happens to use something in that format
[16:34] <persia> Well then, yes, I am violently agreeing :)
[16:34] <slangasek> but I don't think it's worth doing validation, visual or otherwise, against arbitrary wiki revisions
[16:34] <ogra> .oO( all that violence here today )
[16:35] <persia> Oh.  I do it mostly to make sure that the person preparing the file is consistent with their claims, rather than just cargo-culting, but perhaps I tend to review packages in a different stage.
[16:35] <asac> doko: http://paste.ubuntu.com/192694/ ... does this still make sense in karmic? or rather vm commands?
[16:35] <persia> (and I don't want to reject just because the spec changed *again* since the last time they edited debian/copyright)
[16:35] <asac> (for 0.98)
[16:36] <slangasek> persia: right - not validating against arbitrary wiki revisions --> not validating at all :)
[16:36] <doko> asac: afaic classpath can be used with cacao or jamvm
[16:37] <persia> slangasek, Not even validating to ensure that it complies with current policy?
[16:37] <asac> ok thanks
[16:37] <slangasek> persia: policy compliance, sure
[16:37] <slangasek> that's separate
[16:37] <persia> Ah.  I understand.  Yes, I think that's the right choice from the archive-admin viewpoint.
[16:40] <slangasek> doko: I was wondering what to do with pycairo, btw; the Debian package has switched to python-support, is there an equivalent to DH_PYCENTRAL=include-links for python-support that we need to worry about?
[16:40] <nxvl> NCommander: can you please take a look at ug #385605
[16:41] <nxvl> Bug #385605
[16:41] <directhex> doko is about? woo!
[16:42] <doko> slangasek: no, python-support doesn't have this
[16:43] <slangasek> doko: is python-support's behavior consistent with what we're trying to achieve with include-links?
[16:43] <slangasek> doko: btw, did you file those bugs against python-support?  I don't have the bug numbers
[16:43] <mvo> slangasek: no include-links in pysupport
[16:44] <mvo> slangasek: but it seems like the links are now kept during upgrades
[16:44] <doko> slangasek: not yet, will try later.
[16:44] <mvo> (i.e. python-foo keeps working after --unpack but before --configure)
[16:44] <slangasek> doko: ok
[16:44] <slangasek> mvo: alrighty, then I can turn that into a sync
[16:45] <slangasek> mvo: thanks
[16:46] <asac> doko: sorry, but now gjdoc --version gives nullpointer exception :(  http://paste.ubuntu.com/192709/ ... do you know which .properties files its looking for there?
[16:48] <doko> asac: no. gjdoc should work (used in the gcj-4.4 build to build the libgcj docs)
[16:48] <asac> doko: yeah. but i get null pointer like above on --version
[16:49] <asac> classpath 0.98 seems to check version in configure ... and it fails because of this
[16:49] <slangasek> doko: should we transition away python2.4 support in python-stdlib-extensions, btw?  The structuring of that package makes it difficult to tell if the reverse-deps need python 2.4 support
[16:50] <yuriy> calc: ping
[16:50] <\sh> hmm...anyone with more initramfs knowledge then me, could explain what tool inside the initramfs would like to create e.g. /var/run/.ramfs ?
[16:50] <\sh> during bootup that is
[16:52] <doko> slangasek: yes, that's one of the things I want to do next week, together with 2.5
[16:52] <slangasek> oh, then I'll leave it for you :)
[16:58] <doko> does somebody know if today's live images are installable?
[17:00] <ogra> tomorrows should be :)
[17:00] <doko> hmm, no lpia images at all
[17:00] <pitti> doko: yesterday's was fine, anyway; haven't tried today's yet
[17:01] <ogra> and its unlikely you'll see any lpia ones
[17:01] <persia> Wasn't the intent to not have lpia images, intentionally?
[17:01] <ogra> the intent was intentionally, yes :)
[17:02]  * persia scores redundancy points, and seeks a acetylcholine refresh
[17:02] <ogra> *g*
[17:05] <calc> yuriy: hi
[17:05] <yuriy> calc: got my email from a week ago?
[17:06] <calc> yuriy: let me see, i had a huge amount of email to deal with so it might have been overlooked
[17:08] <calc> yuriy: ah ok, i'll look into what should be done, and let you know
[17:08] <calc> yuriy: we have a human project setup i might be able to expand it to include your icons as well
[17:10] <calc> yuriy: taking to privmsg
[17:15] <asac> robbiew: who will own foundations-karmic-eclipse-update ?
[17:15] <sabdfl> rickspencer3-afk, jono: dx call?
[17:15] <rickspencer3-afk> heh
[17:16] <rickspencer3-afk> I just dropped off a few minutes ago
[17:16]  * rickspencer3-afk calling
[17:16] <sabdfl> dbarth is moving house, but i'd like to hear from jono re couchdb and rickspencer3-afk re firefox
[17:17] <calc> yuriy: did you see my messages?
[17:17] <jono> sabdfl, oh, dialling in
[17:27] <ogra> Keybuk, oh, have you seen http://mjg59.livejournal.com/111453.html ? "... The Pre uses upstart as its init application. In contrast to mainstream Linux distributions that still mostly use upstart in sysvinit emulation mode, the Pre appears to be almost entirely based on native upstart events..."
[17:28]  * Keybuk knows ;)
[17:28] <ogra> way cool
[17:29] <slangasek> Keybuk: making a little scratch on the side doing upstart consulting, hmm? :)
[17:29] <Keybuk> I've known for a while in a don't-tell-anyone-but kind of way
[17:29] <Keybuk> slangasek: hah, I wish
[17:29] <Keybuk> then I'd be the one with the 73" HDTV
[17:29]  * slangasek grins
[17:29] <robbiew> lol
[17:29] <ogra> haha
[17:30] <Keybuk> Maemo uses it natively too
[17:30] <ogra> yeah
[17:30] <ogra> but only to fire off hildon
[17:31] <robbiew> asac: don't think we will do the eclipse update
[17:32] <asac> robbiew: well. we have to do something, because it blocks bug 352968
[17:32] <asac> robbiew: we cant keep xul 1.8 in the archive for another round. its just too far eol with too many security issues
[17:33] <robbiew> doko: ^^^
[17:33] <robbiew> doko: any suggestions?
[17:34] <asac> maybe we can rebuild eclipse without the feature that requires gecko?
[17:34] <seb128> if we have an outdated and buggy version and nobody works on it just drop it until somebody does the job to update it?
[17:34] <robbiew> seb128: hmm...you make a good point
[17:35] <asac> seb128: well, that was my idea for those rdepends left on xul 1.8, but archive admins didnt like the idea. see the bug
[17:35] <doko> robbiew: need to email some people about eclipse. did talk to somebody from the eclipse foundation last week
[17:35] <seb128> asac: try to convince slangasek ;-)
[17:35] <asac> my idea was: remove xul 1.8; respin all rdepends and if nobody steps up fixing the build failures, remove them from archive
[17:35] <robbiew> doko: okay
[17:35] <asac> seb128: he commented twice on the bug ;)
[17:35] <seb128> I agree we should make some efforts to try to fix those
[17:36] <seb128> but in the eclipse case if it's outdated for cycles and nobody want to work on it
[17:36] <seb128> it doesn't benefit our user anyway
[17:36] <seb128> users
[17:36] <asac> seb128: i am doing that and i planned to do that, i just think it would be easier to get community contributions when we make those build depends fail
[17:36] <seb128> and it can be uploaded again when somebody wants to do the update
[17:36] <seb128> talk to slangasek on IRC ;-)
[17:36] <robbiew> I recall someone sending an email requesting we update eclipse...
[17:36]  * robbiew looks
[17:36] <slangasek> asac, seb128: I was just backing up StevenK
[17:36] <seb128> might be either that to convince him there than by bug tracker
[17:37] <slangasek> pointing out that nothing had changed
[17:37] <slangasek> I don't have a strong feeling about it :)
[17:37] <asac> slangasek: sure. i might have not communicated the idea appropriately
[17:37] <seb128> let's talk to StevenK to see how strongly he believes about that not being right
[17:37] <seb128> I doubt anybody will object to do that early in the cycle
[17:42] <robbiew> asac: seb128: FWIW, we did receive an email some months ago from a journalist mentioning that he was hearing from some people that only having Eclipse 3.2 in Ubuntu is "driving them nuts"
[17:42] <robbiew> but apparently it's not nuts enough to get them to contribute :)
[17:42] <asac> robbiew: yeah. wonder if its better to not have it than to have such an outdated version.
[17:42] <robbiew> right
[17:42] <ogra> it should live in a PPA
[17:42] <robbiew> that might be the way to go
[17:42] <ogra> and find a maintainer team
[17:43] <robbiew> we should probably wait on doko's email
[17:44]  * doko has some email and other backlogs ... :-/
[17:45] <asac> doko: so seems the old gjdoc thing had a version.properties in a jar. the new thing doesnt have that so --version fails
[17:45] <asac> doko: maybe its because i have messed up alternatives for some java stuff? how can i reset all alternatives to something reasonable?
[17:45] <asac> (strace showed that it picked up rt.jar from the sun jdk)
[17:46] <cody-somerville> doh
[17:46] <cody-somerville> my wireless isn't working in karmic anymore
[17:46] <asac> cody-somerville: chipset?
[17:47] <cody-somerville> asac, BCM4322 802.11a/b/g/n
[17:47] <superm1> cody-somerville, if it was by 'wl', then see bug 381682, bug 381683, bug 381678, bug 381687 bug 381686 and bug 381684
[17:48] <superm1> some of them are taken care of, but the rest need to happen for jockey to be able to offer support now
[17:48] <doko> asac: did you set a java home?
[17:48] <cody-somerville> I'm pretty sure I
[17:48] <superm1> in the interim, you should be able to manually install bcmwl-kernel-source and then blacklist ssb and b43 for now
[17:48] <cody-somerville> Okay
[17:49] <cody-somerville> Thanks :)
[17:49] <superm1> np
[17:49] <asac> doko: my env doesnt have a JAVA_HOME
[17:50] <asac> doko: are those bits in gcc-defaults assembled manually?
[17:50] <doko> no
[17:51] <asac> doko: i cannot find anything in the sources that looks like it produces this gjdoc thing
[17:52] <cody-somerville> superm1, w00t
[17:52] <cody-somerville> superm1, worked like a charm
[17:53] <superm1> cody-somerville, great.  if you want to give a go at solving bug 381682 since rtg hasn't had a chance yet, can get it more OOTB experience for jockey to offer and what not...
[17:53] <asac> doko: so gcc-defaults it build depends on gcj-jdk ... but that package it produced by gcc-defaults itself. sounds like its a bootstrapping thing (manually?)
[17:54] <doko> asac: where is gjdoc --version used?
[17:54] <asac> doko: by classpath configure script
[17:55] <asac> (0.98)
[17:55] <asac> doko: i can patch that check out and assume all is good, but that doesnt sound right. gcj-jdk should ship the version.properties imo
[17:56] <asac> doko: previously  (in gjdoc) the version.properties was in /usr/share/java/gnu-classpath-tools-gjdoc.jar
[18:00] <asac> doko: build failure is: http://launchpadlibrarian.net/27733377/buildlog_ubuntu-karmic-i386.classpath_2%3A0.98-0ubuntu1~asac1_FAILEDTOBUILD.txt.gz
[18:01] <doko> asac: please attach a patch for gcj-4.4. gjdoc shouldn't use this file, but just using the method like other classpath tools
[18:04] <asac> doko: whats the source package?
[18:04] <doko> asac: gcj-4.4
[18:04] <asac> doko: there is nothing in there ;)
[18:05] <doko> run debian/rules patch, then you'll find the tools stuff in src/libjava/classpath/tools
[18:05] <asac> (outside of debian)
[18:05] <doko> gjdoc was recently added, so I assume the version handling stuff is still the old one
[18:07] <asac> doko: http://paste.ubuntu.com/192773/
[18:11] <doko> asac: dpkg-checkbuildeps?
[18:11] <asac> aye
[18:17] <asac> doko: i dont think i understand whats the _new_ way of doing it would be.
[18:18] <asac> the current getGjdocVersion does what i expect: open version.properties and get the version properties from there
[18:19] <doko> asac: look at how e.g. gjavah gets the version information
[18:19] <asac> k
[18:22] <stefanlsd> pitti: During UDS there was a discussion on https://blueprints.launchpad.net/ubuntu/+spec/security-karmic-overview re the syncing of Debian security of to Ubuntu. It was mentioned you had a tool or an idea about this?
[18:22] <pitti> stefanlsd: first time I hear about it
[18:22] <stefanlsd> pitti: oh ok. The notes say - automated Debian-security fetch/try/build system (mom, ubuntuwire (rcbugs), pitti may have some)   -  Not sure who volunteered you :)
[18:23] <jdstrand> pitti: we talked about it
[18:23] <kees> stefanlsd: that was my idea, but there's no code.  :(
[18:24] <pitti> ah, I remember that being mentioned over lunch
[18:24] <jdstrand> it was kees' idea, but he wasn't there that day. we talked about using MoM or rcbugs and I thought you mentioned some scripts that could conceivably help
[18:24] <pitti> anyway, can we talk tomorrow? I need to leave for Taekwondo now
[18:24] <stefanlsd> yeah. np.
[18:24] <pitti> jdstrand: indeed, MoM would be ideal for this
[18:24] <pitti> jdstrand: or, alternatively, adapting http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[18:25] <pitti> anyway, bye everyone (sorry, gotta run)
[18:25] <jdstrand> pitti: I think that was the script you mentioned
[18:25] <jdstrand> bye pitti, have fun! :)
[18:25] <asac> doko: so this part? http://paste.ubuntu.com/192792/
[18:26] <asac> or are you asking to move the whole gjdoc thing to the new ClasspathParser?
[18:27] <doko> asac: yes, gjdoc maybe should use that as the default
[18:29]  * calc wishes old bugs were archived or something to that effect where people can't comment on them anymore
[19:02] <\sh> I wonder which piece of software sets $RAMRUN for /lib/init/mount-functions.sh  or /etc/init.d/mountkernfs.sh
[19:03] <\sh> aha...default rcS
[19:11] <puff> hi, I'm not sure this is the right place, but before I submit this brainstorm suggestion, I wanted to ask aroudn abou tit.
[19:11] <puff> I want to suggest that when a package is removed or renamed, that attempts to install (or even search for) the old package should get some sort of useful response, along the lines of "that package has been renamed to foo" or even "that package has been removed, see bug http://etcc"
[19:24] <robbiew> superm1: ping
[19:26] <superm1> robbiew, pong
[20:36] <mterry> evand1: Did you want any help with karmic installer stuff?  Like the ubiquity slideshow or something?
[20:43] <directhex> has there been a definitive answer to the question "was the audio from UDS recorded?"
[21:18] <slangasek> cody-somerville: do you know why xubuntu livefs builds are still failing due to libgoffice-gtk-0-6 being gone?  I'm not finding any references to that package
[21:19] <slangasek> cody-somerville: n/m, just found it in livecd-rootfs
[21:19] <evand1> mterry: slideshow is going to be mostly marketing, but help with the oem-config stuff, and other installer tasks that crop up (if that's what you're more interested in), would be fantastic.
[21:21] <mterry> evand1: Sure.  I don't want to cause more work in figuring out what to give me, but if you point me at a buglist, maybe I can claim some?  Or however you'd like to do it
[21:21] <evand1> mterry: sure, I'll follow up to Robbie's email tomorrow with more concrete ideas.
[21:22] <mterry> evand1: Cool
[21:37] <ZachD> hello
[21:38] <ZachD> im here to give u guys suggestions on ubuntu and improvements!
[21:38] <ZachD> w00t
[21:38] <cody-somerville> oh joy
[21:38] <ZachD> lol your welcome
[21:41] <directhex> doko, seems ironpython 2 works fine in sid's mono, so that blocker on updating is gone
[21:42] <doko> directhex: yes, it is supposed to work with 2.6
[21:43] <directhex> doko, rudimentary testing seems fine on 2.4 - testing the ipy 2.0.1 stable release, not the ipy 2.6 beta
[21:44] <ZachD> _._
[21:44] <ZachD> -.-
[21:44] <ZachD> whooops
[21:46] <doko> directhex: I'd rather go on with 2.6
[21:46] <directhex> doko, mono 2.6 or ipy 2.6?
[21:52] <sladen> Keybuk: ha.  So the first people using a full native upstart system are ... Palm
[21:53] <Keybuk> sladen: not true, others are doing so before them
[21:53] <Keybuk> from this we can discern two things
[21:53] <Keybuk> assumedly they're using 0.3 natively (based on /etc/event.d)
[21:54] <Keybuk> so the first thing is that they deserve a medal for getting any kind of useful native boot to that
[21:54] <Keybuk> and the second thing
[21:54] <Keybuk> I deserve a complimentary Palm Pre
[21:54] <Keybuk> ,g>
[22:00] <sladen> Keybuk: planning on moving to CDMA land to use it? ;-)
[22:01] <Keybuk> sladen: good point
[22:02] <puff> Anybody here know the guts of apt, dkg, etc?
[22:02] <puff> er, dpkg.
[22:03] <puff> I'm typing up a suggestion for brainstorm.ubuntu.org and I'd like to bounce it off somebody.
[22:04] <sladen> puff: you could try asking anyway.  There are people here who do know those parts of the stack /extremely/ well.  They might, or might not see it, so no promises
[22:05] <Nafallo> either that or it might not be as much of the guts that you fear :-)
[22:05] <puff> Two things, really.
[22:07] <puff> The real suggestion  is that when packages are removed or renamed, the package management system should clue you in, rather htan you being mystified, trying to remember if you spelled it right, googling like crazy and eventually finding the bug report where they discuss why kdiff3 was removed because we upgraded to kde4 and kdiff3 isn't kde4 compatible yet and you can compile it by hand, etc.
[22:07] <puff> Instead, when you enter "sudo apt-get install kdiff3" it should simply say "kdiff3 has been removed from the repositories, see ubuntu bug #11343141, http://etc."
[22:09] <puff> The second would be adding annotations to the installed packages;  apt or whatever would prompt the user for a reason, so you know who installed it and why, and whether it was installed as a result of a dependency or deliberately.
[22:09] <cjwatson> puff: it seems like the sort of thing that could fit better higher up the stack, perhaps in the "appcenter" idea that's being kicked around at the moment
[22:09] <cjwatson> (but I'm not really here)
[22:10] <puff> cjwatson: The first or the second?
[22:11] <Keybuk> both
[22:11] <puff> The second suggestion would particularly aid in situations where you have multiple folks managing multiple boxes, although heck, I've had instances where I was trying to remember to myself why I installed something.
[22:11] <cjwatson> the first; I'm not sure about the second, we do already have a record of whether something was installed as a result of a dependency or deliberately
[22:11] <cjwatson> although no more than that single bit of information
[22:11] <cjwatson> (see apt-mark(8) etc.)
[22:11] <puff> The first seems like it should be more at the repository level, since multiple tools use that.
[22:12] <cjwatson> the reason it belongs higher up is that it's the sort of thing that we might want to add richer information to after the fact
[22:12] <cjwatson> and it would be better for it not to be in the repository since that tends to be harder to change
[22:13] <puff> I guess I can see the reasoning there, but I think it's an 80/20 thing.  80% of the value is in simply knowing that the repository changed in a not-backward-compatible way.  Once you figure that out, it's much easier to hunt down *why* it changed via bug tracking, ubuntu forums, etc.
[22:14] <cjwatson> well, you know *that* due to Provides/Replaces/etc. if people are setting dependency relationships correctly
[22:14] <puff> But until you know that you're looking for something that isn't there anymore, it's kind of a crazy-making situation.
[22:14] <cjwatson> but the fact is that people don't :)
[22:14] <puff> It's bitten me at least twice, which is why I'm making the suggestion.
[22:14] <cjwatson> so it's probably better to have it separate, purely for practical maintenance reasons
[22:15] <cjwatson> right, and I'm applying ten years of experience with this kind of system to direct the suggestion to where it seems most likely to work ;-)
[22:15] <cjwatson> I agree that it would be useful
[22:15] <puff> Ah, I see... put the data somewhere that is less gate-keepered, so more folks canhelp keepit up to date.
[22:15] <cjwatson> but I don't honestly think it's likely to work well in the package metadata itself, even though in some theoretical sense that is the *correct* place
[22:15] <cjwatson> right, exactly
[22:16] <puff> I guess the simplest thing then would be to extend aptitude so it can query some sort of aptwiki-ish thing.
[22:16] <puff> Hm, or maybe just build an ubuntu aptwiki and a simple little aptitude-flavored CLI to it.
[22:16] <puff> With everything keyed by package names, etc.
[22:17] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/software-library is the design work happening on this at the moment
[22:17] <puff> Cool.  I will read and cogitate.
[22:18] <cjwatson> I don't know that your specific suggestion has been taken into account there
[22:18] <cjwatson> but it probably ought to be!
[22:18] <cjwatson> in some sense it comes under error-tolerant search but I think it's probably not quite the same
[22:19] <puff> I like adding GUI tools but I prefer it when they complement, not supersede, the underlying tools.
[22:19] <cjwatson> oh, I agree, I don't believe appcenter is intended to replace apt
[22:20] <cjwatson> mpt is the guy coordinating this, although he's not around right now
[22:20] <puff> I'll read up and try to catch up with him.
[22:21] <robbiew> puff: http://wiki.ubuntu.com/AppCenter
[22:21] <puff> Hm, this might dovetail with another idea I've had, which is to factor in platform-specific feedback.
[22:21] <cjwatson> it seems useful for that kind of thing to have a lower-level interface, of course; much of AppCenter is UI design and there are lots of places where the underlying tools are going to have to be extended a bit, or new tools written
[22:22] <cjwatson> e.g. the support lifetime for a package is going to have to be encoded somewhere
[22:22] <cjwatson> there's been talk of using debtags, which is potentially fairly flexible
[22:22] <cjwatson> still has the problem of the index files being frozen at release but I think debtags can use alternative data sources too
[22:23] <cjwatson> I suspect annotations belong lower down
[22:24] <cjwatson> since that doesn't involve any kind of interaction with us, it's purely local to the system
[22:24] <puff> Yeah, that I was thinking belonged in the dpkg records, somewhere.
[22:24] <puff> Or in a database "alongside" the installed packages stuff.
[22:26] <cjwatson> probably apt, I have this pesky desire to keep dpkg simple
[22:26] <cjwatson> and apt already has the auto/not-auto stuff anyway
[22:26] <cjwatson> (and apt would have to tell dpkg about it anyway so ...)
[22:28] <ebroder> Anybody with main upload bits willing to look at my fix for bug #362691? It's been sitting there for 3 weeks now, and includes a change to the version in jaunty-proposed
[22:29] <cjwatson> ebroder: probably better to ask outside a soft freeze
[22:29] <ebroder> Oh, right. Forgot about that
[22:29] <puff> cjwatson: Well, obviously I need to learn more about this whole topic, apt, dpkg, repos, what info's kept where.
[22:30] <puff> I've been bit several times by issues like this and things like problems with suspend/resume cropping up after dist-upgrading.  It seems really silly for something as cool as ubuntu to have problems like this (not silly for it to have problems, silly for people to be caught unaware by them)
[22:31] <puff> Especially since it's mainly a matter of communicating to the community, which ubuntu is pretty good at.
[22:31] <puff> Okay, thanks, I will go off and do my homework now.  Ciao.
[22:35] <cjwatson> puff: oh, don't take me as saying that there aren't bits of existing dependency relations that could be used - as I say I think there's some value in interpreting Conflicts/Replaces, Provides, etc.
[22:36] <sladen> cjwatson: is the actual example given (of removal of kdiff3) covered.  It was presumbly removed because there wasn't a replacement (although it should have said this in the list)
[22:38] <cjwatson> sladen: I don't know that that particular example is covered by package relationship fields, and I think it's pretty hard to cover there, which is one reason I explicitly wasn't suggesting shoehorning everything into package relationship fields
[22:43] <puff> kdiff3 was apparently removed for a while (and then re-added) due to some ubuntu general switchover to kde4, or something:  https://bugs.launchpad.net/ubuntu/+source/kdiff3/+bug/260326
[22:43] <puff> Previously I ran into something similar where some podcast downloading tool, I think ipodder, mysteriously disappeared (mainly because apple threatened a lawsuit over trademark infringement).
[22:45] <puff> And I've run into problems where I upgraded to a new ubuntu release and fundamental stuff like suspend/resume broke, and then when I went researching it, only *then* did I find out that it was a major known issue with that architecture .
[22:53] <cjwatson> ipodder was replaced by castpodder, but the project kind of petered out AFAICT (at least as far as getting packages was concerned) and I'm not sure if the replacement castpodder ever made it into the archive
[23:19] <lizthegrey> what's the proper procedure for recruiting backport testers for a package and deeming the backport sufficiently tested?  I'm trying to get sudo 1.7.0-1ubuntu1 from karmic backported to dapper and hardy - https://bugs.launchpad.net/hardy-backports/+bug/384100
[23:43] <lifeless> kees: how does one debug/fix apparmor profiles: cups is breaking when apparmor is on, on my laptop
[23:56] <mathiaz> lifeless: https://wiki.ubuntu.com/DebuggingApparmor
[23:56] <lifeless> thanks