[01:39] <GrueMaster> So, I just found another interesting resolvconf failure.  Inside an ubuntu-core image, run "apt-get update && apt-get install ubuntu-minimal".  It will fail on resolvconf.
[01:40] <GrueMaster> start: Unknown job: resolvconf
[01:40] <GrueMaster> invoke-rc.d: initscript resolvconf, action "start" failed.
[01:40] <GrueMaster> dpkg: error processing resolvconf (--configure):
[01:41] <infinity> GrueMaster: Is that running on top of overlayfs?
[01:41] <GrueMaster> No, just chroot.
[01:43] <infinity> GrueMaster: Oh, uh.  It's because you don't have upstart running in the chroot.  Which is somewhat expected.   :P
[01:43] <GrueMaster> (assume sudo su): tar -C Core -zxvf precise-core-armhf.tar.gz && cp /etc/resolv.conf Core/etc && chroot Core.
[01:44] <infinity> GrueMaster: A policy-rc.d that prevents you from starting things would help.
[01:44] <GrueMaster> Ah.  Well, this is a problem.
[01:44] <infinity> GrueMaster: Installing any upstart service in a chroot would have the same result.
[01:46] <GrueMaster> So, why do none of the other packages in ubuntu-minimal have this issue?
[01:47] <GrueMaster> I assume there are other apps that use init.
[01:47] <infinity> Because none of them install upstart services and try to run them?
[01:48] <infinity> Basically, the only two ways upstart can know about a new service is either (A) running some cryptic command that I've now forgotten (but I think we should probably add it as a dpkg trigger), or (B) if upstart is running, it has an inotify hook on /etc/init.
[01:52] <SpamapS> FYI, upstart works fine in chroots
[01:52] <broder> initctl reload-configuration
[01:52] <SpamapS> yeah that works
[01:52] <broder> but you need, uh, natty's upstart or newer outside the chroot
[01:52] <SpamapS> yeah
[01:53] <GrueMaster> Ah, well that would be problematic then.
[01:53] <SpamapS> and you don't need initctl reload-configuration for the initial start/stop .. but you do need it after that if you are chrooted on top of overlayfs, because overlayfs is broken
[01:53] <SpamapS> (some inotify bug)
[01:53] <GrueMaster> I wonder how our buildds did it on the babbages?
[01:53] <broder> a dpkg trigger wouldn't be an unreasonable way to work around overlayfs+inotify sucking
[01:54] <SpamapS> GrueMaster: no build will work if it depends on an upstart job AFAICT
[01:54] <SpamapS> broder: well in mk-sbuild chroots, policy.d denies starting jobs anyway
[01:54] <broder> SpamapS: right, but there's a livecd issue
[01:54] <SpamapS> policy-rc.d rather.. or whatever its called
[01:55] <SpamapS> broder: I think we should actually be able to fix overlayfs.. very troubling to me that its broken.
[01:55]  * SpamapS wanders off to eat dinner.
[01:56] <broder> good plan :)
[02:09] <infinity> SpamapS: Fixing inotify in overlayfs is a much tougher problem than it looks like at first blush.  apw and I have talked circles around it a few times.
[02:11] <infinity> GrueMaster: buildds have no issues with it because we use a null policy-rc.d during livefs builds.
[02:11] <GrueMaster> ah
[02:42] <kees> any ubuntu folks going to https://events.linuxfoundation.org/events/collaboration-summit/request-an-invitation ?
[03:00] <TheMuso> @pilot out
[03:55] <sephthir> I have a question regarding Ubuntu install image ISO creation, but no one seems to ever be in the #ubuntu-iso channel. Does anyone have contact info for someone who might be able to answer my question?
[03:56] <broder> sephthir: just asking in here has a decent chance of finding an answer
[03:57] <sephthir> Alright, I wasn't entirely sure if this was a decent place to ask. What I really need is the method by which the Ubuntu alternate install discs are created, but I can't seem to find any documentation on it. Does anyone know where I might be able to find info on how they're created?
[04:41] <pitti> Good morning
[05:14] <tjaalton> theres no ubotu on #ubuntu-x, how to get it back?
[05:16] <micahg> tjaalton: ask in #ubuntu-irc I think
[05:16] <tjaalton> micahg: ok, thanks
[06:51] <micahg> pitti: for gmime2.4, if dh-cli is useful, why not duplicate it in the arch dependent build deps?
[06:51] <pitti> micahg: becuase it pulls in a gazillion build depends
[06:52] <pitti> and I think meebey's main point of having it in B-D-I was to allow much quicker -B builds
[06:52] <micahg> ah, ok
[06:52] <pitti> it's how the previous debian/rules worked
[06:52] <pitti> I just inadvertently broke it when moving from "-include cli.mk" to "dh --with cli"
[06:52] <pitti> (the "-" was the trick)
[07:01] <micahg> \o/ powerpc backlog clear
[07:21] <pitti> micahg: wait until Laney starts the ghc transition :)
[07:21] <pitti> or ":(" rather
[07:21] <andy7534211> I have two packages in ubuntu that have updates that I would like to get in for precise
[07:22] <andy7534211> i submitted update requests last week (Bug 933299 and 933303) with a link to the packages in my PPA, but it was suggested that I wait for them to get into debian first and then get a Feature Freeze exception
[07:23] <micahg> pitti: most of ghc won't go very far on powerpc due to ghc-ghci being dropped (unless it was added back)
[07:23] <pitti> meh, is it just me, or does pretty much every UDD branch fall over due to pre-applied quilt stuff?
[07:24] <andy7534211> however, they still haven't made it into Debian. should i keep waiting or should I ask someone to upload the packages from the PPA?
[07:25] <micahg> andy7534211: if you're the Debian maintainer, see if one of the Ubuntu DDs would be willing to sponsor it for you
[07:26] <micahg> andy7534211: since they're team maintained, have you asked in #debian-science?
[07:29] <andy7534211> i emailed the debian-science list yesterday after i was unable to contact the sponsor for the packages, but i guess he saw that email because he uploaded one of the packages (it's in the Debian New queue now)
[07:29] <andy7534211> but the second packages (aweather) depends on the first, so that's not in the queue yet
[07:29] <micahg> ah, ok, so we should just wait then
[07:30] <andy7534211> ok, i was wondering because the beta freeze is coming up and i wasn't sure if it would be possible to get a freeze exception for that
[07:31] <micahg> as tumbleweed  mentioned they're leaf apps (well, co-dependent leaf apps), so an FFe shouldn't be that hard
[07:31] <andy7534211> ok, so that's still true during the beta freeze as well?
[07:32] <andy7534211> oh, i guess there's a `feature freeze' period between the two beta releases..
[07:34] <micahg> final freeze for universe if a few days before release, that's the only period it would be almost impossible to get an exception, I don't suggest waiting an inordinately long time, but just past beta 1 (about a week from now) shouldn't be much of a problem
[07:34] <micahg> s/if/is/
[07:35] <andy7534211> great, thanks for clarifying that for me
[07:39] <sephthir> does anyone know where I might find more information about how the ubuntu install isos are built?
[07:41] <micahg> pitti: have you seen http://blog.bazaar.canonical.com/?p=405
[07:41] <pitti> micahg: yes, I did; but that doesn't seem to be in precise yet
[07:41] <pitti> bzr: ERROR: unknown command "quilt-commit-policy"
[07:42] <poolie> mm i think this needs to be in ~/.bazaar/builddeb.conf or something
[07:42] <poolie> yes
[07:42] <poolie> it's not a command
[07:42] <pitti> oh
[07:42] <poolie> hth, let me know
[08:10] <dholbach> good morning
[08:26] <micahg> to refresh my memory, we can only not explicitly depend on stuff that's Priority: required and Essential:yes, right?
[09:58] <kklimonda> hey, any idea if debian/ubuntu allows init scripts to take arguments?
[09:58] <kklimonda> (arguments additional to status/start/stop etc.)
[09:59] <kklimonda> so you can call them like "/etc/init.d/service status X")
[10:08] <tumbleweed> kklimonda: http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit the single action argument is a "should" not a "must", so it's not entirely illegal.
[10:14] <kklimonda> tumbleweed: hmm, not entirely illegal makes it sound like not entirely good idea :)
[10:14] <tumbleweed> kklimonda: as long as it's an extra feature and "status" still works as expected, I don't see any problem
[10:15] <Laney> pitti: actually I think infinity will be pulling the trigger this time ;)
[10:15] <Laney> plausible deniability
[10:16] <pitti> *chuckle*
[10:16] <kklimonda> tumbleweed: hmm, makes sense - thanks
[10:16] <pitti> Laney: I'm fairly sure the powerpc buildds won't care much :)
[10:16] <Laney> heh
[10:16] <tumbleweed> whoah, no ppc build queue, I'm impressed
[10:16] <tumbleweed> Laney: fix that
[10:17] <Laney> any one of you can start it; it's an easy merge :P
[10:17]  * Laney is doing some rebuilds in Debian instead, for now
[10:19] <Laney> actually two easy merges (ghc and haskell-devscripts)
[10:22] <pitti> diwic, seb128: I like the new audio settings capplet; it makes more sense than the old one
[10:23] <seb128> pitti, yeah, kudos to ronoc on #ubuntu-desktop as well who did most of the ui work
[10:23] <diwic> pitti, thanks :-)
[10:23] <seb128> (and is still doing)
[10:24] <diwic> ...and christian, and Allan Day from gnome design, and...
[10:25] <seb128> diwic, is that work going upstream?
[10:25] <seb128> because right now we have a forked codebase :-(
[10:26] <diwic> seb128, I intend to try once PulseAudio 2.0 is released
[10:26] <seb128> diwic, great
[10:27] <diwic> seb128, we're having some distro patches to PulseAudio 1.1 for this functionality to work, and they will (most likely) go in PulseAudio 2.0
[10:27] <seb128> ok
[10:28] <diwic> so I doubt upstream Gnome would take it before they have a stable PA release to test it agains.
[10:28] <diwic> s/agains/against
[10:32]  * diwic notices that today's updates brings in version "1.0.0-1pitti1" of remmina, and recognised the name in the version more than the application itself
[10:35] <JokerInDisguise> I was following this guide http://mhall119.com/2012/02/contributing-to-unity-for-non-developers-quicklists/ . "bzr branch ubuntu:totem" fails with "OUT-OF-DATE" error. Any idea?
[11:02] <Hi_the> About GoogleSoC2012
[11:03] <Hi_the> improving speed of code generate by gcc
[11:03] <Hi_the> sets
[11:03] <Hi_the> ?
[11:38] <brendand> JokerInDisguise, that's not an error. at least i see the same thing and the branch is succesful
[11:40] <JokerInDisguise> brendand: not successful for me. http://paste.ubuntu.com/852530/
[11:40] <brendand> JokerInDisguise, this is the error: bzr: ERROR: Target directory "" already exists.
[11:41] <brendand> JokerInDisguise, what command did you run exactly?
[11:41] <JokerInDisguise> bzr branch ubuntu:totem
[11:41] <brendand> JokerInDisguise, does the directory 'totem' already exist?
[11:41] <JokerInDisguise> bradm: No, its empty folder.
[11:42] <doko> chrisccoulson, what was the reason for dropping libxul.pc?  apparently the headers are still there
[11:42] <JokerInDisguise> brendand: wrong mention, sorry..
[11:43] <chrisccoulson> doko, nobody should be using libxul.pc. it only existed for embedders and extensions that needed to link against libxul
[11:43] <dholbach> Laney, seb128: did any of you have a bit of time to review goocanvasmm-2.0 or libgdamm5.0 in my PPA? :)
[11:43] <chrisccoulson> the only thing that was using it was mozvoikko, but that is now pure-JS, so there should be nothing at all in the archive using it
[11:43] <chrisccoulson> the headers might go at some point too ;)
[11:43] <Laney> no sorry, just go ahead; there's nothing that can't be fixed later i'm sure
[11:43] <doko> chrisccoulson, I hope not before the lts. and what should be used instead?
[11:44] <chrisccoulson> doko - the only headers that should be used are the npapi headers (which i wouldn't get rid of)
[11:44] <dholbach> thanks Laney, seb128
[11:45] <seb128> dholbach, thanks for working on that
[11:45] <dholbach> thanks murrayc and the openismus folks :)
[11:45] <doko> chrisccoulson, ok, thanks
[11:47] <doko> chrisccoulson, #include <npruntime.h>
[11:47] <doko> #include <npfunctions.h>
[11:47] <doko> are these kept as well>?
[11:47] <chrisccoulson> doko, yeah, those are fine
[11:49] <dholbach> seb128, Laney: uploaded
[11:49] <seb128> dholbach, danke
[11:49] <Laney> dholbach: sorry for not doing it
[11:49] <Laney> i want to help it get into debian, but not enough fingers for all of the pies
[11:50] <dholbach> I'm sure that if we stay on top of things and get glom in, we can help Murray and the Openismus maintain it afterwards - they defacto maintain it in their PPA anyway already
[11:50] <doko> seb128, g_thread_init was deprecated, wasn't it? and what was the replacement?
[11:51] <seb128> doko, yes it is
[11:51] <seb128> doko, nothing, glib init it for you
[11:51] <seb128> doko, just drop the call
[11:52] <doko> seb128, and for which glib/gtk versions do I need to keep it?
[11:54] <seb128> doko, it's deprecated since 2.31
[11:54] <seb128> i.e this cycle
[11:54] <seb128> well things should just build fine with it if you don't use G_DISABLE_DEPRECATED
[11:56] <doko> hmm, glib_init isn't called in the library
[12:00] <brendand> JokerInDisguise, i can't directly see what the problem is without being able to poke around. Are you using Precise?
[12:01] <JokerInDisguise> brendand: yeah, I'm on Precise, fully updated.
[12:14] <dholbach> geser, could it be that the results of the application of nataliabidart was not announced yet? or did I miss a memo?
[12:20] <geser> dholbach: could be, the DMB lacks sometimes to reply with the result to an application on devel-permissions
[12:21] <dholbach> ok
[12:21] <geser> checking right now it it was acted on at least
[12:26] <geser> dholbach: it was acted on, nessita has upload right for the ubuntuone packageset, so only the announcement is missing
[12:26] <dholbach> excellent
[12:26] <dholbach> thanks a bunch geser
[12:27]  * nessita feels the ping
[12:27] <nessita> hello everyone!
[12:27] <dholbach> hey nessita :)
[12:27]  * dholbach hugs nessita
[12:27] <nessita> hola dholbach! /me hugs back :-)
[12:31] <debfx> doko: yodl MIR ping, bug #920436
[12:31] <debfx> I really want to update zsh this cycle
[12:33] <dholbach> doko, I'm not sure if barry noticed, but sphinx FTBFS because python-whoosh is in universe (it's just needed for a fraction of the test suite and builds easily without it) - what do you think we should do about it?
[12:35] <tumbleweed> dholbach: I thought he uploaded a fix
[12:35] <dholbach> oh yeah?
[12:36] <tumbleweed> yip, it's in NEW
[12:36] <dholbach> oops, yeah, you're right
[12:37] <dholbach> nevermind then :)
[12:51] <Cas-> doko, are you able to apply https://bitbucket.org/tarek/distribute/changeset/191f38f47256 as it's a fix to a bug introduced in distribute (0.6.16-1) update
[12:52] <Cas-> this is for Oneiric
[13:22] <doko> Cas-, can you file an issue and prepare a SRU?
[13:48] <pitti> ev: btw, how is apport/whoopsie supposed to work after release?
[13:49] <pitti> ev: usually we disable it completely in /etc/default/apport
[13:49] <pitti> ev: but I suppose that would also stop whoopsie-daisy?
[13:49] <seb128> ev, pitti: how is that apport,whoopsie thing supposed to work? do we still get bugs in launchpad the same way as before?
[13:49] <ev> pitti: funny you should mention that. I was discussing it this morning with apw this morning
[13:50] <pitti> seb128: yes, we want to, at least until the crash db can create bug reports by itself
[13:50] <pitti> seb128: for now we need to upload them twice
[13:50] <seb128> good
[13:50] <ev> pitti: I'll have to craft a branch to move the check of /etc/default/apport to when it wants to open the browser and file in launchpad
[13:50] <seb128> I was wondering if the work I put on improving GNOME hooks was going to be wasted
[13:50] <pitti> ev: I noticed a couple of other regressions, e. g. it lost the ability to display an existing bug if it has a DuplicateOf field; I guess I'll file bugs for that and the issues identified in the MP
[13:51] <ev> pitti: please do
[13:51] <pitti> ev: we should be aware that leaving /e/d/apport enabled (i. e. the core dump and zipping) is a rather large overhead for stable releases
[13:51] <pitti> as it consumes quite a bit of CPU and IO, and leaves the crashing program in limbo during that
[13:52] <seb128> ev, pitti: yeah, please don't do that
[13:52] <seb128> it leads to user having things "freezing" for a minute rather than going down and respawning
[13:52] <ogra_> hey, but its fun on arm :P
[13:52] <ev> hmm
[13:53] <ev> I'm struggling to think of a way in which we do that only if the crash signature has been seen before
[13:54] <ev> as the database/launchpad/whatever might not be contactable at this time
[13:54] <pitti> we need the core dump to determine the crash signatuer
[13:54] <ev> ah and then there's that :)
[13:55] <ev> could we at least factor out the zipping?
[13:55] <pitti> yes, that should work
[13:55] <pitti> although that might not actually help
[13:55] <ev> I was tempted to look into Snappy anyway, as it might be a bit better than gzip for sending this out
[13:55] <pitti> as core dumps compress well
[13:55] <pitti> so instead of writing 0.5 MB compressed you'd then write 50 MB
[13:56] <pitti> so trading CPU against much larger IO
[13:56] <ev> of course we could stick to gzip; what I just said is not really relevant to the discussion
[13:56] <ev> right
[13:56] <ev> hm
[13:56] <pitti> what could help is to write data/apport in C or Vala, or find a quicker way to do the gzipping
[13:56] <seb128> ev, pitti: if you let in on one stable you want at least display a dialog when the collecting start explaining which cpu usage raise and stuff hang
[13:56] <ev> oh god please not vala :)
[13:57] <seb128> ev, pitti: we already get quite some users in unstable series confused by that nowadays
[13:57] <seb128> like their bug description is "was doing nothing and then nautilus froze for 5 minutes and closed"
[13:57] <seb128> the froze for 5 minutes is apport
[13:58] <pitti> ev: or we find a clever way of piping it through /bin/gzip instead of using python's gzip module
[13:58] <pitti> I haven't checked whether that helps significantly
[13:58] <pitti> ev: actually, writing it into a tmpfs uncompressed ought to work
[13:58] <pitti> /var/run/
[13:59] <pitti> then the process can die quickly at least
[13:59] <ev> yeah
[14:01] <ev> as for compression, I believe there are several algorithms that are less resource intensive than gzip, snappy included
[14:01] <ev> whether that bit is something we can fit into 12.04, *shrugs*
[14:02] <pitti> ev: I was thinking, apport could feed it without compression to /var/run/<tmpfile>
[14:02] <pitti> ev: then close stdin, so that the process can die
[14:02] <pitti> and then do whatever it wants with the tmpfile
[14:02] <ev> right, and I guess it doesn't matter what it does after that as the process is gone
[14:02] <pitti> instead of piping it thorugh the gzip module
[14:02] <ev> indeed
[14:02] <pitti> well, it still uses CPU/IO, but at least it doesn't hang the process
[14:03] <ev> right
[14:03] <pitti> and if we only want a crash signature, we don't even need to compress it, etc.
[14:03] <seb128> that would be much better indeed
[14:03] <pitti> we can just run gdb right away
[14:03] <pitti> it's quite a different way of doing things than we do right now, though
[14:03] <pitti> and in development/Launchpad bug filing mode it's not really optimal
[14:03] <pitti> as you'd do the gdb call all the time, even if you don't want to file a bug
[14:04]  * pitti is just brainstorming here
[14:04] <ev> sure, though we should optimize for the common case, which would be the release being out the door and people using this thing for years :)
[14:05] <seb128> I'm still unsure those people want to be bothered at all about software issues
[14:06] <pitti> ev: bug 938700 FYI
[14:07] <pitti> seb128: oh, AFAIUI the apport UI shouldn't pop up any more
[14:07] <pitti> I mean, not the full one, anyway
[14:07] <seb128> pitti, well still having any ui popping is annoying
[14:07] <pitti> I understand it'd only send the sig to whoopsie-daisy
[14:07] <pitti> it's still bothering, of course
[14:07] <pitti> (and I can't say I'm a fan of that)
[14:07] <ev> seb128: the only way we're ever going to get a real picture of the most pressing issues is if we ask everyone
[14:08] <pitti> I still think we should disable it after 6 months or so after it's out
[14:08] <ev> hey, I'd love it to all happen in the background
[14:08] <seb128> ev, well, users are not beta testers ;-)
[14:08] <seb128> especially seeing how few issues we fix on stable compared to the number of report
[14:09] <seb128> we keep getting annoyed user asking why we bother them and make them send feedback if we don't fix bugs in stable anyway
[14:09] <ev> seb128: I'm not pretending users are beta testers. But if we don't find out what's going wrong on people's machines post-release, regardless of whether they're a developer, technical user, or anyone else, then we'll only have a very narrow and potentially inaccurate picture of the quality of the software we ship
[14:10] <seb128> which is a somewhat misleading view, we fix bugs, but yeah we know about issues before shipping stable
[14:10] <seb128> ev, we know our software is buggy and we know before shipping it
[14:10] <ev> we're not filing bugs with this, and that's part of the point. The interface isn't creating an expectation that something's going to be fixed and there's something you can follow along with
[14:10] <ev> seb128: :D
[14:10] <ev> it's definitely a fire and forget thing here
[14:10] <seb128> ev, well I still think it annoys users for no good reason
[14:11] <seb128> we already know about the major issues and we already don't work on those because we don't have the manpower, priorities, etc
[14:11] <ev> we don't know about the major issues
[14:11] <seb128> we do
[14:11] <ev> what if there's a problem in a piece of software that's more commonly used by the vast majority of our users than by developers and beta testers?
[14:11] <seb128> or said differently, your system applied to an unstable cycle gives enough metric to know
[14:12] <ev> ah
[14:12] <ev> that still falls under my previous point
[14:12] <seb128> but otherwise what pitti said
[14:12] <seb128> we should probably disable it after 3 months of a stable cycle then
[14:12] <ev> it will skew the results to the behavior of early adopters
[14:12] <seb128> by then we get enough datas
[14:12] <seb128> no point to annoy user for 5 years when we don't fix most bugs on stable anyway
[14:13] <seb128> it could be different if we were actively maintaining stable versions
[14:14] <ev> seb128: and if something completely falls apart four years in and affects 80% of our users on a stable release? Shouldn't we at least have the data so we can make an informed decision on whether we should be investing the resources in fixing it?
[14:14] <ev> every other serious operating system out there does this
[14:15] <ev> on OSX and Windows, crash reporting is a continuous thing, throughout the entire lifecycle of the product
[14:17] <seb128> ev, yeah, sorry for sidetracking the discussion on that
[14:18] <seb128> ev, it's something I always hated in microsoft oses and liked in Ubuntu, no annoying dialog about issues in stable versions
[14:18] <ScottK> I think it's an assumption that you learn enough about the crashes pre-release to consider what needs post-release changes.
[14:18] <seb128> ev, I got people who stop what they are doing and call for help when they get one of those under windows
[14:19] <ev> seb128: you can turn it off very easily via the control center
[14:20] <seb128> ev, the people who stop what they were doing and come to call for help when they get one of those dialogs don't go to system settings though
[14:20] <seb128> ev, but yeah, it's a tradeoff, I'm not convinced the change is a win
[14:21] <seb128> but that's not a situation where there is a clear win
[14:21] <seb128> there are side cost either way
[14:23] <ev> seb128: we'll surely see whether we know more or not once the release is out the door and this project has had a bit of time to mature
[14:23] <seb128> right
[14:24] <seb128> ev, it's just that I've the feeling that we know about hundred of importants bugs but don't have any resources to work on them anyway
[14:24] <seb128> so adding to that list is not going to help a lot
[14:24] <seb128> but let's see maybe it shows a different picture and will be useful ;-)
[14:24] <ev> indeed, just think of it as a better bug heat algorithm, if that helps :)
[14:25] <seb128> I will be interested to compare what comes out of it and how that matches or not our current picture
[14:25] <seb128> ev, if the pictures are similar though I might try pushing to have it turned off in stable versions for the benefit of users :p
[14:25] <ev> seb128: you're welcome to make any argument you want. I'll be sure to have plenty of counter arguments ready :-P
[14:25] <seb128> ev, ;-)
[14:26] <ev> and failing that, pistols at dawn!
[14:26] <pitti> ev: my current collection: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=whoopsie-merge
[14:26] <seb128> ev, anyway I didn't mean that discussion to be negative, I'm really looking forward have a db and all your work landing
[14:26] <pitti> ev: I subscribed mpt to the two design-ish ones, as you said in teh MP
[14:26] <seb128> ev, I'm mostly discussing details ;-)
[14:27] <ev> seb128: absolutely, and I appreciate that
[14:27] <ev> pitti: cheers!
[14:27] <ev> pitti: I'll add to that tag as I see bugs, and fix them as quickly as I can
[14:28] <sforshee> seb128, re bug 933710, gnome upstream has commented on the upstream bug report that the workaround I supplied makes sense, as the required support isn't likely to be added to X in the short term. Can we go ahead and get the workaround (or something similar) applied?
[14:31] <pitti> ev: I guess we'll leave the two design ones for mpt to return?
[14:31] <pitti> ev: (I don't think either is particularly importnat)
[14:32] <pitti> ev: the "known bug" one is fairly important, though; do you want to look into this, or want me to?
[14:32] <pitti> ev: nice gtk test suite, btw!
[14:34] <ev> pitti: I don't mind, I can look at it now if you're busy
[14:35] <ev> pitti: cheers on the test suite. If you're unfamiliar with Mock and need help understanding it, do let me know
[14:35] <pitti> ev: I'm chasing apport bugs, but different ones
[14:35] <ev> it's a wonderful tool in small doses
[14:35] <ev> okay, I'll have a look
[14:36] <pitti> ev: I have recently used a different mocking library (in aptdaemon), but not this one
[14:36] <pitti> ev: so @patch.object(GTKUserInterface, 'can_examine_locally')
[14:36] <pitti> ev: that means, you can pre-set a return value, and it records if it was called, and delivers that?
[14:37] <pitti> ev: I do that in the main test suite, but with something like myobject.mymethod = lambda self, args: return 'foo'
[14:37] <ev> pitti: it means, turn the member can_examine_locally into a Mock object.  At the end of this method, return the member to its original value
[14:37] <ev> the
[14:37] <ev> any call to the mock object will succeed, and any member or method on that mock object will magically exist
[14:38] <ev> return_value sets what actually gets returned on method calls
[14:38] <ev> and yes, it also tracks calls
[14:39] <ev> so you can assert that a function was called with particular arguments
[14:39] <ev> For what it's worth, Michael Foord, who works for Canonical, is the upstream author
[14:39] <pitti> ev: I guess we'll leave the two design ones for mpt to return?        self.app.get_desktop_entry.return_value.getIcon.return_value = 'nonexistent'
[14:39] <pitti> eek, how did that happen
[14:39] <ev> :D
[14:40] <pitti> ev: so for that call, it would mean that get_desktop_entry() would return an object with a getIcon() method which returns 'nonexistant'?
[14:40] <ev> and yeah, he'll be back on the 27th
[14:40] <ev> correct
[14:40] <pitti> I just pressed middle mouse, and weechat decided to also reply one of my earlier IRC messages, d'oh
[14:42] <ev> :)
[14:56] <barry> mdke: ping: https://launchpadlibrarian.net/92012331/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.2_FAILEDTOBUILD.txt.gz
[15:41] <chrysn> i'm having trouble tracing a ppa's build failure down; it's about the openscad - 2011.12-2precise2 build on the https://launchpad.net/~chrysn/+archive/openscad/+packages archive
[15:42] <chrysn> i reproduced the build setup by installing an lxc virtual machine, made sure the dependencies are met with exactly the versions the build server used, and removed abundant packages (a -dev recommended another -dev) until the diff between my and the server's build log was reduced to build directory path differences
[15:44] <chrysn> nevertheless, i get an undefined reference error where i know from the line number that the file used on the ubuntu build server contains the #include <GL/glu.h> line, and i've looked at the package the build server downloaded to satisfy the respective dependency, and it has a GL/glu.h which does define what the error is about
[15:45] <chrysn> any ideas what i could have been missing?
[15:45] <pitti> ev: hang on, that dupe problem is not your fault; unless you started on it already, I'll take it
[15:45] <ev> pitti: I haven't gotten to it yet, so by all means :)
[15:46] <infinity> chrysn: It should fail the same locally too, that's not a PPA issue.
[15:46] <pitti> seems it's due to some recent Launchpad change
[15:46] <ev> ahh
[15:46] <infinity> chrysn: And it's probably due to the order of arguments on your linking line.
[15:47] <chrysn> is there a way to fetch the intermediate files from the build server to look for differences there?
[15:47] <infinity> chrysn: Nope, it's all thrown away after the build and the VM reset.
[15:48] <chrysn> but that would show up anyway in the build log, wouldn't it? and that is the g++ line that fails is the same both on my system and the build server
[16:13] <Cas-> doko, i'm just filling out an issue what should I put for SRU?
[16:15] <doko> Cas-, a branch, or a debdiff
[16:16] <Cas-> its in distribute release
[16:16] <Cas-> this seems like a lot of hoops for such a simple fix
[16:19] <Cas-> doko, https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/938786
[16:21] <doko> Cas-, and subscribe ubuntu-sru
[16:25] <Cas-> k
[16:27] <pitti> ev: https://launchpadlibrarian.net/93753132/Traceback.txt (from bug 938625) looks very weird -- could this be a threading issue?
[16:38] <doko> Cas-, I can't see a branch or a debdiff in the report
[16:44] <ev> pitti: my initial suspicion is that something is calling addbutton for the bug report dialog, which doesn't have a button box anymore. Digging.
[16:51] <ev> pitti: presumably something like this would work: http://paste.ubuntu.com/852898/ but I'm still trying to see what is calling addbutton for that dialog
[17:17] <bdmurray> psusi: is zeroing the superblock the right way to get your array going again in bug 925280?
[18:11] <psusi> bdmurray: no, you don't want to zero the superblock, doing that and then adding the drive is like adding a completely new drive
[18:12] <bdmurray> psusi: then what would be the right thing?
[18:12] <psusi> bdmurray: you either need to enable the write-intent bitmap when you set up the array, and then you can --re-add the removed drive, or you need to --add --run ( both switches together ) to add the drive back, or zero the superblock, then -add it
[18:14] <psusi> best is to just enable the write-intent bitmap, then you can --re-add the drive and it will sync back up fast
[18:15] <bdmurray> is there a way to enable that for an existing array?
[18:17] <psusi> sure, just pass the -b internal switch same as when you create the array
[18:40] <stgraber> infinity: any idea about bug 938867?
[18:41] <infinity> stgraber: Oh, ugh.  The tidying in hacks doesn't run late enough.
[18:41] <infinity> stgraber: (Which now makes me wonder why any of said tidying is in that block of code...)
[18:42] <infinity> stgraber: I'll just revert that for now, and then look for a better way to do it a bit later.
[18:47] <infinity> stgraber: Uploaded a revert.  I'll try to sort out a better place to do cleaning a bit later (and probably move all the other cleaning from _hacks at the same time)
[18:55] <Cas-> doko, why can't the upstream versin of distribute be used?
[19:49] <barry> mdke: ping
[19:49] <mdke> barry: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
[19:49] <barry> mdke: https://launchpadlibrarian.net/92012331/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.2_FAILEDTOBUILD.txt.gz
[20:07] <doko> Cas-, we only fixing issues in stable releases, not updating to new upstream versions
[20:09] <Cas-> i understand that but surely for such a crucial part of python the bugs should not be just left and fixed ad-hoc
[20:09] <Cas-> http://pypi.python.org/pypi/distribute#changes
[21:11] <micahg> infinity: please refresh my memory, if it's not essential:yes + priority: required, it needs to be depended on in some form?
[21:38] <seb128> jdstrand, hey
[21:40] <seb128> jdstrand, evince has some apparmor related bug and I would like your input, that's the best way? subscribe you or ubuntu-security? irc pings?
[21:41] <broder> micahg: i thought you had to explicitly depend on anything that wasn't essential:yes
[21:42] <broder> micahg: http://www.debian.org/doc/debian-policy/ch-binary.html#s-dependencies is the relevant policy snippet
[21:47] <micahg> fun, AFAICT, there's not an awk providing binary that's essential :)
[21:49] <broder> wait, was the conclusion from yesterday that you get to keep the pieces of a system without ubuntu-minimal breaks?
[21:50] <broder> because if so, it's purely an exercise in pedantry
[21:51] <micahg> I seem to have missed that discussion
[21:51] <micahg> but I do have a bug report :)
[21:51] <broder> micahg: http://irclogs.ubuntu.com/2012/02/21/%23ubuntu-devel.html#t22:53
[21:55] <micahg> umm, well, this one's a little different, a system can in theory live just fine without awk
[21:55] <broder> right. the relevant portion of the discussion was whether or not you're allowed to run ubuntu without ubuntu-minimal installed
[21:55] <micahg> I guess I should start a thread on ubuntu-devel
[21:55] <micahg> well, that seems to be a difference of opinion :)
[21:56] <broder> well, if you're not allowed to complain about things being broken without ubuntu-minimal, then effectively everything in ubuntu-minimal becomes "essential", and you don't have to depend on them explicitly
[21:56] <chrisccoulson> huh, since when can a system run fine without awk?
[21:56] <micahg> since I had to a while back add a dependency for locales to firefox which is in minimal, I don't think this is much more of a stretch
[21:56] <chrisccoulson> it's a pre-depend of an essential package (ie, base-files)
[21:56] <chrisccoulson> which makes it, essential
[21:57] <micahg> ah, it's transitively essential then :-/
[21:57] <broder> essential-ness isn't transitive. it *is* guaranteed to be installed, but that's an implementational detail
[21:57] <micahg> right
[21:57] <broder> so you're still *supposed* to depend on it if you need it
[21:57] <chrisccoulson> awk is a virtual package, so it can't be made essential
[21:57] <chrisccoulson> but it is essential by virtue of being a pre-depend of an essential package
[21:58] <micahg> right, so we'd have to make an implementation of it essential to fulfill the pre-depends
[21:58] <chrisccoulson> if awk isn't installed and configured, your system is screwed ;)
[21:58] <broder> micahg: no, you just have to make an implementation priority:required
[21:58] <micahg> oh, well, we already have that
[21:58] <broder> right
[21:59] <broder> but, the only dependencies you don't have to explicitly list are packages which are themselves essential:yes
[21:59] <broder> and for the purposes of dependencies, that essential-ness is not transitive
[21:59] <broder> technically you're *supposed* to depend on awk
[21:59] <micahg> well, that's the thing, mawk isn't essential: yes, but is priority:required
[21:59] <broder> micahg: then if you have a package that uses it, you're supposed to depend on it
[22:00] <broder> but because it's pulled in by an essential package, this is all pedantry and not relevant to actual practice
[22:00] <micahg> right, but since an essential package needs it, maybe it should be essential as well
[22:00] <chrisccoulson> you can't make a virtual package essential
[22:00] <broder> no, i don't think that's how it works
[22:00] <broder> the entire essential dependency chain doesn't need to all be essential
[22:00] <broder> just priority:required
[22:01] <broder> e.g. you don't tag libraries essential, even though they're obviously depended on by essential packages
[22:01] <broder> (and you don't want to, because then you'd never be able to remove the old version in the case of a SONAME bump)
[22:02] <micahg> ok, then we should add the pre-depends for awk like base-files has
[22:03]  * micahg googles for discussions in Debian on this point
[22:04] <micahg> ooh, the discussion almost pre-dates some Ubuntu contributors :) http://lists.debian.org/debian-policy/1998/02/msg00072.html
[22:04] <chrisccoulson> nothing should need to pre-depend on awk when base-files already does
[22:04] <micahg> chrisccoulson: that's a technicality
[22:07] <broder> well, the thread makes it pretty clear that the intent was to treat awk as essential
[22:08] <micahg> yeah, I guess so, so I'll just close the bug as an issue with the uses's system I guess
[22:53] <micahg> kenvandine: please try to remember -v in your merges :)


[00:25] <[Ketchup]> hi
[00:33] <ramrebol> a litte question: there exists some "nautilus-open-terminal" for xubuntu ??
[00:34] <ramrebol> without installing nautilus (I thing that install nautilus is not a good idea)
[00:39] <klys> hmm do you use nemo instead?  a terminal for gnome, you want?  terminator?
[00:43] <klys> ramrebol, have you fixed your wi-fi yet?  iwconfig; ifconfig wlan0 up <IP_ADDRESS>; iwlist wlan0 scan | less; editor /etc/wpa_supplicant.conf; wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant.conf &
[00:47] <ramrebol> yes klys, thanks. After install the xubuntu-restricted-extras , appears as "extra drivers" the wifi option. So, wifi is working perfect now :)
[00:48] <ramrebol> klys: I'm using only the terminal comming from xubuntu by default
[00:49] <ramrebol> but, "terminator" has an "nautilus-open-terminal" option?
[00:50] <ramrebol> I'm using an old netbook, thats why I need to use the "more light" option for all
[00:55] <klys> well I'm not too sure, haven't used nautilus in a while.  there is likely a solution around if you search [nautilus open terminal here]
[00:57] <ramrebol> thanks klys . I will try it.
[00:57] <krytarik> ramrebol: http://bazaar.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/view/head:/etc/xdg/xdg-xubuntu/Thunar/uca.xml.in#L26 - so it should be there in Xubuntu by default.
[01:11] <ramrebol> thank krytarik again :)
[02:21] <willie_> I'm running Xubuntu 16.04.3 and in the Power Manager, there aren't isn't an option for what to do when closing the lid on my laptop. Why is that? I see it in screenshots.
[02:22] <cfhowlett> willie: eh?  not offered on my system either.  could be that the website needs updating.
[02:59] <RoadRunner|2> Not getting sound in youtube or in a flash player plugin in Firefox (sound from audio or video players is fine). Using Xub 16.04 with latest software updates. Help?
[03:07] <cfhowlett> RoadRunner|2, ps -x | grep pulseaudio
[03:08] <cfhowlett> kill -9 the puluseaudio number then restart your sound app
[03:08] <cfhowlett> also ensure you haven't muted your browser tab
[03:19] <RoadRunner|2> cfhowlett: so the problem is due to pulseaudio not working right with flash player by default?
[03:20] <cfhowlett> RoadRunner|2, depending on your settings.  personally, I disable flash in the browser thus requiring explicit authorization each time
[03:20] <cfhowlett> but your browser should be throwing a permission box for same.  did you miss it?
[03:21] <RoadRunner|2> no, I've alowed it
[03:21] <RoadRunner|2> could you please explain the syntax of the command you gave above?
[03:22] <cfhowlett> ps -x = list all processes
[03:22] <cfhowlett> grep foo = filter previous list for foo
[03:22] <cfhowlett> kill = well, kill
[03:22] <cfhowlett> kill -9 = kill when you absolutely, positively must leave no survivors
[03:25] <RoadRunner|2> cfhowlett: https://paste.ubuntu.com/26481564/
[03:26] <cfhowlett> yep, kill -9 1855              that ? = process not running normally
[03:27] <cfhowlett> I believe s<1   has special meaning as well
[03:28] <RoadRunner|2> how do we know that "1855" is the pulseaudion number?
[03:28] <cfhowlett> line 2
[03:28] <cfhowlett> and line 3 is the command you ran: ps -x | grep pulseaudio
[03:29] <cfhowlett> well, line 3 is the OUTPUT of your command
[03:29] <cfhowlett> eh, no
[03:29] <cfhowlett> line 3 is the new process launched by your command
[03:29] <cfhowlett> line 2 = output
[03:34] <RoadRunner|2> ok, tried, "kill -9 1855 " and restarted the browser after - no diff
[03:37] <RoadRunner|2> cfhowlett: the problem continues https://paste.ubuntu.com/26481608/
[03:39] <cfhowlett> RoadRunner|2, bring this to #ubuntu
[03:39] <RoadRunner|2> is this a know issue?
[03:40] <cfhowlett> happens to all of us.
[03:40] <cfhowlett> for various reasons
[03:40] <RoadRunner|2> so there are diff solutions to this in diff situations?
[03:40] <RoadRunner|2> ... on diff systems?
[03:41] <cfhowlett> on *buntu, yes
[03:41] <RoadRunner|2> also, what did you mean by "ensure you haven't muted your browser tab" muted where?
[03:41] <cfhowlett> ffox tabs can be muted.  if mute = no sound
[03:43] <RoadRunner|2> didn't even know this feature was there:) but no, my tabs where not muted :)
[03:43] <RoadRunner|2> so I guess to #ubuntu I go...
[03:44] <RoadRunner|2> I just fear that they may send me right back here...
[03:44] <cfhowlett> RoadRunner|2, your issue is not restricted to xubuntu
[03:45] <RoadRunner|2> before I go, do any other possible solutions come to mind?
[03:45] <cfhowlett> none.  sorry.
[03:45] <RoadRunner|2> thanks for you help, any effort is much appreciated
[09:30] <aizaz> hello guys
[09:30] <aizaz> Could someone here help me with an issue i am having with Xubuntu 17.10 (freshly installed) subversion and gnome-keyring
[09:31] <aizaz> I am using svn, version 1.9.7  for my development and while checking out / update/ commit, the repo asks me for the password
[09:32] <aizaz> I expect gnome-keyring to save the password however it doesn't work. Interesting, the passwords of my ssh sessions is stored by gnome-keyring
[09:33] <aizaz> I tried to explicitly specify in subversion config file to use gnome-keyring as password store
[09:33] <aizaz> this also didn't help
[09:33] <aizaz> I search for any bug reports, didn't find any. I am not sure what to do. I don't want to save passwords unencryprted locally
[09:37] <aizaz> anyone who has a similar experience could perhaps give me some pointers.
[09:41] <well_laid_lawn> aizaz:  tried this https://askubuntu.com/questions/206604/svn-and-gnome-keyring#206609 ?
[09:42] <aizaz> @well_laid_lawn: yes I actually removed the complete .subversion folder; didn't help either, I am not sure whether the problem lies with the keyring or svn
[09:44] <aizaz> this however states if i don't want to use any password stores; but I do, i do want to use password store
[09:49] <well_laid_lawn> are you sure the daemon is running ?
[09:49] <well_laid_lawn> https://wiki.archlinux.org/index.php/GNOME_Keyring#With_a_display_manager
[09:58] <aizaz> yes I do: 1412  0.0  0.0 430080  7876 ?        Sl   10:22   0:00 /usr/bin/gnome-keyring-daemon --daemonize --login
[09:58] <aizaz> infact I made sure with seahorse to verify if the keyring is unlocked at login
[09:58] <aizaz> and it is
[09:59] <aizaz> this is exactly my issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577818
[10:19] <aizaz> Is it possible if I can downgrade the version of subversion to 1.9.3 in Xubuntu 17.10
[10:20] <aizaz> I don't see any other candidates for installation available in apt-cache policy
[10:20] <aizaz> subversion:   Installed: 1.9.7-2ubuntu1   Candidate: 1.9.7-2ubuntu1   Version table:  *** 1.9.7-2ubuntu1 500         500 http://de.archive.ubuntu.com/ubuntu artful/main amd64 Packages         100 /var/lib/dpkg/status
[10:29] <aizaz> perhaps this is the way to go? https://packages.ubuntu.com/xenial/amd64/subversion/download


[08:51] <SteveA> hi everyone!
[12:13] <statik> hi aquarius, i'm having trouble with desktopcouch/local_files.py. it imports the ubuntuone module, which is a bogus dependency i think
[12:13] <statik> but now i'm a bit stuck figuring out how to replace the is_in_source_tree() code
[12:15] <statik> of course, i figured out a way around it as soon as i said that
[12:16] <SteveA> Chipaca: hi john
[12:16] <Chipaca> hi SteveA!
[12:16] <Chipaca> SteveA: face duty?
[12:16] <SteveA> Chipaca: I'm the help contact today, and I'm replying to a thead on the ubuntuone-users list
[12:16] <SteveA> yep
[12:17] <SteveA> a user reports geting a conflict when trying to put a .zip file into their My Files folder
[12:17] <SteveA> but no conflict with the same file but under another name
[12:17] <SteveA> we don't do anything special for .zip files, do we?
[12:17] <Chipaca> nope
[12:17] <Chipaca> let me see the email...
[12:19] <Chipaca> SteveA: what was the subject of the email?
[12:20] <SteveA> "file renamed"
[12:21] <aquarius> statik, yeah, just seen rick's bug about that
[12:21] <kenvandine> statik, i just pushed a fix in the packaging branch for the missing dep
[12:22] <kenvandine> statik, ok if we wait on getting that sponsored? since folks should have u1 installed by default?
[12:22] <aquarius> statik, I'm confused. my desktopcouch/local_files.py doesn't import ubuntuone
[12:22] <SteveA> Chipaca: I just replied to that thread
[12:22] <kenvandine> i figure we will have more stuff this week :)
[12:22] <kenvandine> aquarius, i just added the dep
[12:22] <kenvandine> aquarius, weird
[12:23] <aquarius> kenvandine, aha, gotcha. Yeah, rick's right; we don't want desktopcouch to depend on ubuntuone
[12:23] <Chipaca> SteveA: found it, thanks
[12:23] <kenvandine> well
[12:23] <kenvandine> we need to refactor then
[12:23] <kenvandine> chad pushed a change that uses uuid from it or something
[12:24] <Chipaca> SteveA: I'm not sure if it's been deployed, but there was a window for spurious conflicts until recently
[12:24] <Chipaca> SteveA: related to not telling the difference between an empty file and a file that hasn't been uploaded to yet
[12:24] <aquarius> ah, I needed to pull again
[12:24] <SteveA> Chipaca: was that the same kind of think I was seeing when trying to edit a new file in vim?
[12:24] <SteveA> I'd often get a conflict, even thoughI was the sole users
[12:25] <kenvandine> aquarius, it looks like it is using that to detect if it is a local checkout or not
[12:25] <aquarius> kenvandine, yep, but I'm not sure why it's looking at ubuntuone to discover that. desktopcouch is a different source tree
[12:25] <kenvandine> yeah, it shouldn't :)
[12:26] <aquarius> it didn't look at ubuntuone before...and now I can't remember how it worked before because I've overwritten it by pulling :)
[12:26] <kenvandine> i will revert my packaging change then
[12:26] <kenvandine> aquarius, it was changed in revision 14.6.5
[12:28] <Chipaca> SteveA: no, the editing in vim was because of a bug in syncdaemon itself, which has been fixed and released
[12:29] <Chipaca> SteveA: now if you install syncdaemon, we helpfully uninstall vim :-P
[12:29] <Chipaca> it's for your own good, really
[12:29] <aquarius> kenvandine, bzr: ERROR: Requested revision: u'14.6.5' does not exist in branch: BzrBranch7('file:///home/aquarius/canonical/ubunet/desktopcouch/')
[12:29] <kenvandine> ok... well i don't know bzr well enough
[12:29] <kenvandine> use blame :)
[12:30] <kenvandine> bzr blame desktopcouch/local_files.py
[12:30] <statik> i don't particularly like that code, but i just proposed a branch that makes the dependency less horrible
[12:30] <CardinalFang> statik, Maybe we should drop the generated PNGs/GIFs and make the browser render data.  http://vis.stanford.edu/protovis/ex/  (end)
[12:31] <statik> CardinalFang, for the file previews?
[12:31] <statik> dobey, did you publish review-tool in a public project?
[12:32] <CardinalFang> No, :)    Launchpad statistics, at least.
[12:32] <CardinalFang> There's another place we make graphs.... .
[12:33] <CardinalFang> statik, https://bugs.edge.launchpad.net/ubunet/+bug/377540
[12:35] <statik> CardinalFang, doesn't launchpad already draw the graphs directly on a <canvas> element using javascript?
[12:35] <CardinalFang> statik, Maybe.  Dozer?
[12:36] <statik> ah
[12:36] <statik> dozer is using pil to generate images
[12:37] <statik> wow it is really annoying that clicking disconnect on the applet doesn't seem to disconnect or stop the spinning
[12:37] <statik> CardinalFang, btw did you get to talk to the gwibber guy yesterday?
[12:38] <CardinalFang> statik, Yes.  I started on making Gwibber read/write account info to couchdb.
[12:39] <statik> sweet!
[12:39] <statik> i heard there were some other changes needed to gwibber in order to get gwibber 2.0 into karmic, do you know what those are?
[12:41] <kenvandine> statik, http://live.gnome.org/Gwibber/Roadmap
[12:41] <statik> jblount, files/new/ is not showing a bunch of the filenames for me using firefox-3.5 on karmic
[12:41] <CardinalFang> statik, aquarius, When I started poking data into desktopcouch, I realized I don't have some ideas fleshed out.  What should the database name be?  Shared among all apps, perhaps?  Gwibber doesn't have a canonical web site, so I had to make up a record_type.  I hope this is okay.  ...
[12:46] <statik> CardinalFang, aquarius would know better than me.
[12:50] <aquarius> CardinalFang, there's a distinction between storing data for a specific application and storing data that other apps may share. Account info sounds to me like a shareable sort of thing. Making up a record type is fine -- the convention is that the URL should point to a description of the record, but it's not enforced. (The convention should be followed where possible, though)
[12:51] <aquarius> CardinalFang, database name is an interesting one. I suggest storing the data in a "gwibber" database. If, in the future, there's a desktop-wide shared collection of this account data, then inventing a "social_networks" database and changing gwibber to use it seems a good idea.
[12:52] <CardinalFang> aquarius, Rgr.
[12:52] <aquarius> CardinalFang, I'm open to discussion on any of this stuff, btw :)
[12:53] <SteveA> aquarius, CardinalFang: I was thinking about gwibber/couch integration on Friday in London
[12:53] <SteveA> I'd like to talk through it with y'all.  Gwibber has two different models of using contacts -- much like IM applications do
[12:53] <SteveA> for some services, like twitter, the service itself records who you are following, online
[12:54] <SteveA> and there is one feed to use your own login to read it
[12:54] <aquarius> Gwibber's a weird one, because it is (a) an application and (b) a proposed Gateway To Social Networks for all other applications, and how all its data should be stored differs dramatically between these two use cases
[12:54] <SteveA> for other services (like following Atom feeds of blogs in gwibber) you say who you are following on your own machine
[12:54] <SteveA> in your own database
[12:54]  * CardinalFang nods.
[12:54] <SteveA> this is a bit like an IM application where with AOL IM, you ask the AOL server who your buddies are
[12:54] <SteveA> same for Jabber
[12:55] <SteveA> same for skype
[12:55] <SteveA> in these cases, I think we (eventually) should have a syncing arrangement
[12:55] <SteveA> where we sync the contact info in a user's couchdb with the info stored in the online service (Jabber, twitter, aol, etc)
[12:55] <CardinalFang> SteveA, So, mirror locally what the remote end knows to be a contact list.
[12:55] <aquarius> much like pidgin does, hence the "buddy X is on your local list but not in the server list; do you want to add them?"
[12:56] <SteveA> aquarius: yes, that kind of thing
[12:56] <SteveA> CardinalFang: yes.  But, we also have different concepts of a contact to map
[12:56] <SteveA> in CouchDB on the desktop for contacts, we have the idea of a person, a contact record
[12:56] <SteveA> and in that person's record, we have various means of contacting them
[12:57] <SteveA> or seeing information about them
[12:57] <SteveA> but compare that to twitter -- there is no distinction between Stephen Fry's twitter identity and his alter-ego Mrs Stephen Fry
[12:58] <SteveA> in my couchdb, they'd be the same person record who has two twitter feeds
[13:09]  * SteveA --> lunch
[13:58] <SteveA> re
[14:05] <dobey> statik: not yet
[15:00] <jblount> MEETING BEGINS
[15:00] <jblount> People of desktop+, let your voice be heard! A simple "me" (or similar) will get you into the role of todays standup, and tomorrows future.
[15:00] <jblount> s/role/roll
[15:00] <jblount> me
[15:00] <urbanape> moi
[15:01] <aquarius> me
[15:01] <vds> me
[15:02] <jblount> CardinalFang, dobey, statik ?
[15:03] <jblount> DONE: Got some more css quirks completed yesterday
[15:03] <jblount> TODO: Lots of triage, try to track down what's going down with "live" /files/new truncating stuff
[15:03] <jblount> BLOCKED: Nope
[15:03] <jblount> urbanape: You know what to do
[15:03] <urbanape> DONE: submitted the new UI sharing branch (finally!) with massive help from mars in #rhinos.
[15:03] <urbanape> TODO: Cranking through on the newui bugs now that the bare (just barely) functionality is present.
[15:03] <urbanape> BLOCK: nada
[15:03] <urbanape> AGE OF AQUARIUS! AQUAAAAARIUS! AQUAAAAAARIUS!
[15:03] <aquarius> ⚀ DONE: evaluate couchdbkit; lots of cool stuff going into couch upstream; frustrating day
[15:03] <aquarius> ⚁ TODO: piston oauth in snowy; learn about process groups; branch to do desktopcouch startup
[15:03] <aquarius> ⚂ BLOCKED: none
[15:03] <aquarius> Alas, poor vds: I knew him, Horatio
[15:03] <vds> DONE: fixed nasty bug in one of my branch, waiting to fix an issue with cloud_server before proposing that branch again, waiting for funambol_cared branch to be approved, discussed about funambol exchange deployment.
[15:03] <vds> TODO: land both branches, continue with the deployment of fx
[15:03] <vds> BLOCKED: nope
[15:04] <vds> no one else?
[15:04] <urbanape> slackers
[15:04] <jblount> vds: No one else me'd, so we'll EOM for now, let them paste when they get a chance :)
[15:04] <jblount> END OF MEETING
[15:04] <CardinalFang> me
[15:04] <CardinalFang> dang!
[15:06] <CardinalFang> DONE: most of spawning/paste integration.  Starting Gwibber/desktopcouch integration.
[15:07] <CardinalFang> TODO: finish spawning/paste, at least.
[15:07] <CardinalFang> TODO: finish spawning/paste, at least.  Maybe Gwibber.  Ideas, anyone?  https://wiki.ubuntu.com/Gwibber/DesktopCouch
[15:07] <CardinalFang> BLOCKED: None.
[15:07] <CardinalFang> Next!
[15:07]  * CardinalFang dereference null pointer.
[15:07]  * CardinalFang crashes.
[15:07] <jblount> heh
[15:08] <aquarius> CardinalFang, what's "record_version"?
[15:08] <aquarius> CardinalFang, that wants to be record_type_version :)
[15:08] <CardinalFang> aquarius, You're prob right.
[15:09] <aquarius> and I'd suggest adding record_type explicitly to the spec on that page as well (in the json dump)
[15:10] <aquarius> things that are completely specific to gwibber should go in application_annotations, but I'm not sure there are any. message_colour is...debatable.
[15:10] <aquarius> what's account_id for? the document gets an ID anyway
[15:11] <CardinalFang> Yeah, I'm about to refactor that away.  Currently, I'm sharing space with GConf, and using its IDs.
[15:17] <rodrigo_> CardinalFang: we are adding record_type pages to freedesktop -> http://www.freedesktop.org/wiki/Specifications/desktopcouch
[15:17] <rodrigo_> CardinalFang: so add it there when you're happy with it, please :)
[15:18] <rodrigo_> dobey: can you please review https://launchpad.net/~rodrigo-moya/couchdb-glib/set-get-uuids/+merge/9660 ? We are waiting to do a release on that branch
[15:19] <dobey> @reviewers
[15:19] <CardinalFang> rodrigo_, Oh, that's prefect.  I feel better seeing that than making up my own information.
[15:20] <rodrigo_> CardinalFang: cool :)
[15:21] <aquarius> rodrigo_, CardinalFang: I'm not sure about adding the gwibber record pages to the freedesktop wiki
[15:21] <aquarius> thos pages aren't meant to be documentation of every record type that exists (people should not feel constrained to add their record types to the freedesktop wiki!)
[15:21] <rodrigo_> aquarius: well, if it's only for gwibber, right, but this is about online services accounts, right?
[15:21] <aquarius> rodrigo_, yeah, but the record type for these records isn't a freedesktop url
[15:22] <aquarius> and I don't want to encourage people to think that all recordtypes live at freedesktop
[15:22] <rodrigo_> aquarius: because we don't have the xdg page yet :)
[15:22] <aquarius> gwibber records seem a perfect example of something that shouldn't be a centralised freedesktop url record
[15:22] <aquarius> they're semi-specific to gwibber
[15:22] <aquarius> I am sort of on the fence about this particular example, I admit it
[15:23] <rodrigo_> ah, if it's specific to gwibber, ok, but I see it could be extended to be an 'accounts' record type, right?
[15:23] <aquarius> yes, definitely
[15:25] <aquarius> I'd just like there to be some examples of non-generic record types, and the gwibber ones seem like a good example. This is the conflict in what gwibber's for: is it an app for monitoring feeds of your social networks, or is it a gateway to social networks for the whole desktop with a little GUI on top of it?
[15:28] <rodrigo_> yeah, right
[16:06] <SteveA> jcastro: hi jorge!
[16:06] <jcastro> hi SteveA!
[16:33] <jdo> my ubuntuone icon is spinning. is there a way to find out what it's doing?
[16:33] <jdo> I didn't update anything
[17:04] <dobey> jdo: syncdaemon log should tell you the current state
[20:50] <druid2> hello, sorry for my english.
[20:51] <druid2> i have a question: can ubuntuone client show upload progress?
[20:53] <jblount> druid2: If you do "u1sdtool --current-transfers" in a terminal, you can get upload / download progress
[20:53] <jblount> We'll have that in the ui shortly
[20:53] <druid2> thank you
[20:54] <jblount> druid2: Sure thing :)
[22:39] <peppertarts> Hi all, does anyone know how to validate a computer with UbuntuOne after the computer has been removed using the web interface?
[22:40] <dobey> peppertarts: you'll need to remove the "UbuntuOne token" from the Passwords tab in Accessories->Passwords and Encryption Keys
[22:40] <dobey> though that will behave more appropriately soon
[22:41] <peppertarts> dobey: Excellent, that's got it. Thanks.
[22:59] <aquarius> dobey, should that be a FAQ?
[23:00] <aquarius> there's an interesting question. peppertarts, can I ask whether you looked at our faq list for an answer to that question?
[23:24] <peppertarts> I looked in the 'Support' section, the 'Known issues' section and browsed through some of the bugs. I haven't come across a FAQ page, is it on ubuntuone.com? A link to it in the support section would be handy.


[03:43] <hackfu> Hello
[03:51] <marcoceppi> hackfu: o/
[18:55] <hackfu> Good morning.
[18:56] <marcoceppi> hackfu: it's a bit more in the afternoon here in DC ;)
[18:57] <hackfu> some of us just woke up from a long night ;D
[18:58] <hackfu> Where do you live marcoceppi?
[18:59] <marcoceppi> hackfu: I'm in Falls Church actually
[18:59] <hackfu> I'm in the heart of DC.
[18:59] <hackfu> on Dupont Circle
[19:00] <marcoceppi> Nice, I'm looking for a place to move in to the city proper in a few months, so hopefully I'll finally be "legit" ;)
[19:01] <hackfu> http://www.washingtonpost.com/local/guerrilla-gardener-returns-to-dupont-circle/2013/10/27/7122f3ba-3f35-11e3-9c8b-e8deeb3c755b_gallery.html
[19:06] <hackfu> DC vigilante.


[18:39]  * shel3over eating
[21:34] <shel3over> http://people.ubuntu.com/~chilicuil/ubuntumembers-map.html !!! where is DZ ?
[22:54] <ino> DZ it connect to thé youporn.com
[23:18] <ino> just out of cardboard http://www.freebsd.org/releases/10.1R/announce.html


[01:13] <munz> ping itnet7
[01:30] <bluebomber_satel> Hi.
[01:30] <bluebomber_satel> Woohoo for SELF! Can't wait!
[01:36] <munz> lucky :)
[01:36]  * munz happy for you
[01:52] <bluebomber_satel> Thanks! You should go, too.
[14:46] <munz> itnet7: ping
[15:08] <mint_> hi
[15:10] <mint_> im having an issue with ccsm? it breaks my windows and i lose -+x up top, so i restart and now i get a busy icon for like  5 or 6 minutes....im on a live disc mint 10 i have installed  mint 11 how can i disable ccsm so i can get back to my original desktop?
[15:23] <itnet7> munz: pong
[15:27] <mhall119> mint didn't stick around very long
[16:06] <munz>  lol itnet7
[16:06] <munz> so, i have been thinking and have decided to have a loco meetup up my way (daytona beach)
[16:07] <munz> starting either late july or very start of aug
[16:07] <munz> have a few peeps that i know should attend
[16:07] <munz> possibly a few more maybes
[16:08] <munz> just wanted to discuss stuff w/u as a brainstorm
[16:08] <munz> like what i should do, what has been done, what works, etc
[16:09] <munz> i have a few venue ideas
[16:10] <mhall119> munz: put it in loco.ubuntu.com
[16:12] <munz> ok
[16:13] <munz> should i have a date decided before i put it there?
[16:31] <mhall119> it helps, yeah
[16:31] <mhall119> I don't think you can create an event without a date
[16:35] <itnet7> munz, what kind of a meetup are you thinking of? Just a social thing? Bug Jam style? Installfest?
[16:38] <itnet7> When selecting a venue, call the place or talk with the manager in person. Let them know your intentions and how many you anticipate will attend. See if they can reserve an area for you with little or no cost. Usually most places are good as long as everyone buys at least a drink and something to eat
[16:40] <itnet7> Take out your laptop, Test their wifi to see if it's decent, Look at the area that your going to be (if they reserve a small room or something) and check and see if there is plenty of power available. If there is plenty, Then that is definitely a plus! If not bring powerstrips and some tape to secure the cords temporarily to the floor
[16:41] <itnet7> I will back in a bit after lunch but that should give you some little ideas that you can keep in mind when picking a venue.
[16:48] <munz> cool, thanks. i think for starters a social thing but i have great asperations for more. I have never done a bug jam or installfest but all sounds good.
[16:49] <munz> launch partys etc
[16:49] <munz> bbl
[21:32] <mhall119> crashsystems: ping
[21:36] <crashsystems> pong
[21:37] <crashsystems> I'm here mhall119
[22:07] <raubvogel> Does anyone know why are missing releases in http://archive.ubuntu.com/ubuntu/dists ?
[23:01] <crashsystems> mhall119: if you wanted to tell/ask me something, but don't want to play IRC tag, feel free to email me. I believe you have my address.


[00:09] <billisnice> what programming language is mainly used in Ubuntu development?
[00:21] <TheMuso> billisnice: Python is used a fair bit.
[00:23] <cjwatson> also quite a bit of C (and too many other languages to list, at varying concentrations), and packaging requires make and shell
[00:23] <cjwatson> flexibility to pick up new languages quickly is more important than raw proficiency in any single language, IMO
[00:24] <TheMuso> Agreed.
[00:49] <hdon> cjwatson: yes, thanks, someone else already schooled me about those particular macros ;)
[00:59] <LlamaZorz> Hey guys,does anybody know when firefox forks for the flash plugin?
[01:16] <slangasek> james_w: debian/squeeze/egenix-mx-base also out of date
[01:17] <slangasek> james_w: in this case, debian/egenix-mx-base also appears to be out of date
[01:57]  * cody-somerville wonders why dbus-daemon would be eating up 30-50% cpu.
[01:59] <fagan> cody-somerville: it depends on the traffic
[01:59] <fagan> its either that or its a bug
[01:59] <cody-somerville> strace shows it polling over and over and over and each time it says resource unavailable
[01:59] <fagan> weird
[01:59] <cody-somerville> I'm thinking its a bug in gnome-system-monitor since gnome-system-monitor is refusing to exit now
[02:00] <m4t> dbus-monitor show anything?
[02:00] <cody-somerville> oh yes
[02:00] <cody-somerville> just as I suspected
[02:00] <fagan> gnome-system-monitor is a hog anyway
[02:00] <m4t> hrm which monitors do you have enabled?
[02:01] <cody-somerville> I think its trying to get info about two loop back devices I have mounted
[02:01] <fagan> Are the devices properly mounted and recognised at the moment?
[02:03] <m4t> maybe i have 'gnome-system-monitor' confused with the system monitor panel applet
[02:03] <fagan> m4t: system>admin>system monitor
[02:03] <cody-somerville> ah
[02:03] <m4t> yea. /usr/bin/gnome-system-monitor
[02:03] <cody-somerville> it was actually the cd in my cdrom drive that was the problem
[02:04] <cody-somerville> after ejecting it, gnome-system-monitor quit and dbus is much quieter now.
[02:04]  * m4t uses htop for that sort of thing
[02:04] <m4t> no pretty graphs though
[02:04]  * fagan doesnt use cds anymore
[02:05]  * fagan loves the pretty graphs
[02:07] <fagan> I cant wait for the UDS :)
[02:09] <chrisccoulson> cody-somerville - i've seen that issue with gnome-system-monitor as well (and there's a bug report for it too)
[02:10] <chrisccoulson> it actually seems like a loop in gvfs somewhere
[02:10] <fagan> cody-somerville: how do you force an upgrade to lucid?
[02:13]  * fagan got it, good google :)
[02:25] <sconklin> I am obviously missing something - how can I change the date in karmic - I need to set it into the past to workaround a bug
[02:26] <sconklin> The admin applet changes it back, even though manual configuration is selected
[02:30] <mustakrakish> need help with PGP key for repo's http://paste.ubuntu.com/316517/
[02:32] <mustakrakish> need help with *GPG key for repo's http://paste.ubuntu.com/316517/
[02:33] <cjwatson> mustakrakish: #ubuntu, please
[02:34] <maxb> mustakrakish: That is not a development question, so is offtopic for this channel. Please see the general user support channel, which is #ubuntu .
[02:57] <new_to_linux> hi
[02:57] <fagan> new_to_linux: hi
[02:58] <new_to_linux> please help, there is no install button in ubuntu software centre
[02:58] <mustakrakish> apply
[02:58] <new_to_linux> i just switched from windows
[02:58] <ScottK> new_to_linux: The best channel for getting questions like that answered in #ubuntu.
[02:58] <new_to_linux> ScottK: thanks
[07:46] <dholbach> good morning
[07:46] <smwn> morning
[07:47] <dholbach> hi smwn
[07:50] <smwn> can I hear a w00p
[07:50] <pitti> Good morning
[07:50] <dholbach> smwn: http://photos-c.ak.fbcdn.net/hphotos-ak-snc1/hs202.snc1/6935_251765935091_893075091_8788600_1697850_n.jpg
[07:52] <smwn> HAHA
[08:19] <\sh> moins
[11:08] <liw> tkamppeter, I got my Brother label printer to work yesterday; what's the best way to get that support included in Ubuntu (on the assumption that I don't want to maintain it myself)? should I file a bug and if so, against which package?
[11:50] <tkamppeter> liw, how did you get your printer to work? Did you download a driver? Is the driver free software? Is it from Brother
[11:51] <tkamppeter> pitti, hi
[11:51] <pitti> hi tkamppeter
[11:52]  * pitti fiddles with tzdata's 3.0 package format until it works with launchpad again
[11:59] <tkamppeter> pitti, it is about the auto-downloadable drivers. Does Ubuntu ship any download keys for any hardware manufacturers, like NVidia or so?
[12:00] <Riddell> pitti: amichair is a new member of Team Kubuntu and has been fixing various bugs in Kubuntu apps recently.  he's looking at jockey-kde today and may have some questions to get into the codebase
[12:01] <pitti> Riddell: oh, great
[12:01] <pitti> amichair: hello :)
[12:01] <pitti> tkamppeter: no, not right now
[12:01] <amichair> pitti: hey there
[12:02] <pitti> tkamppeter: ideally we wouldn't need to, and just download them on demand; that would require them to be signed by a key that we already trust, though
[12:02] <pitti> tkamppeter: (well, we need to trust the key either way)
[12:04] <amichair> pitti: first thing, I'm just looking through jokey-kde bug reports, and I can't quite distinguish between backend and gui bugs (most of them just say 'crash') - do u have more specific info on something I can start out with?
[12:05] <amichair> pitti: second, I notice there are a bunch of sys.exits around - is this normal? is there nothing requiring orderly shutdown in there?
[12:05] <pitti> amichair: I'm afraid you have to look at the stack trace; a d-bus error is a backend crash, while most of the rest (sigsegv, etc.) are most probably bugs in python-qt4 or python-kde4
[12:06] <pitti> amichair: without calling sys.exit(), there are some remaining processes/threads which aren't autocleaned for some reason
[12:06] <amichair> pitti: hmmm...
[12:07] <pitti> amichair: bug 458662 is similar
[12:07] <pitti> amichair: (please note that I didn't actually write most of jockey-kde)
[12:08] <amichair> pitti: (and I have no previous dev experience with linux, kubuntu, kde, qt or pythong... I think we'll make a great team! :-) )
[12:08] <pitti> hah
[12:08] <tkamppeter> pitti, the concept is that manufacturers supply the keys and the distros include the keys from manufacturers which they trust.
[12:08] <pitti> tkamppeter: well, those are two different "trust" here
[12:08] <pitti> tkamppeter: we can decide which manufacturer we trust to build good packages -- those are the ones which we can offer
[12:09] <pitti> tkamppeter: but trusting a key is entirely different, it requires identity verification
[12:09] <tkamppeter> pitti, this way the distros have to trust the manufacturers and not the LF and only manufacturers and not the LF take responsibility.
[12:09] <liw> tkamppeter, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555892 has details
[12:09] <pitti> i. e. a trusted path through signatures to their key
[12:10] <pitti> tkamppeter: so, if the manufacturer's key is signed by someone who we trust, we can just download it on demand; but conversely, if we can't trust the manufacturer's key, then shipping the key by default doesn't increase the confidence in it by any way
[12:10] <pitti> (to the contrary, we would make ourselves untrustworthy with key handling)
[12:12] <tkamppeter> pitti, so what do I need to tell the manufacturers what they have to do with their keys so that their packages get auto-downloaded? Who must sign their keys so that all distros accept their keys?
[12:13] <directhex> are we not autosyncing new packages from squeeze?
[12:14] <ScottK> We are.
[12:14] <ScottK> Autosync is not, however, a continuous process
[12:14] <Keybuk> or, in fact, an automatic process ;)
[12:14] <ScottK> It's done periodically.
[12:15] <ScottK> That too
[12:15] <directhex> how periodic? the packages i'm noticing were all in squeeze when karmic shipped
[12:15] <pitti> tkamppeter: well, you know how key signing works?
[12:15] <ScottK> Well it's run once since then.
[12:16] <pitti> tkamppeter: either there's a central authority (like the LF) that generates a key and signs driver manufacturer keys, or we have to meet with them directly to sign them
[12:16] <pitti> tkamppeter: in the first case, all distros would sign the LF key, and the LF woudl sign all the manufacturer keys; in the second case, each distro has to sign each manufacturer key
[12:19] <slangasek> directhex: it's conceivable that there hasn't been a new package sync run yet, I know I didn't make it that far on archive day on account of spending my time updating the sync blacklist for existing packages instead
[12:19] <slangasek> Keybuk: have some time to talk about boot-time hdparm settings?
[12:19] <directhex> slangasek, oh, debian syncs still go into binary NEW don't they? let me check
[12:19] <tkamppeter> I know about keysigning session where people meet physically and sign the GPG keys of each other, is a physical meeting of a Ubuntu/Canonical representative with one representative of each manufacturer needed for this signing? Or is there a way by internet and phone to do this?
[12:20] <Keybuk> slangasek: sure
[12:20] <tkamppeter> pitti: ^^
[12:21] <slangasek> Keybuk: so it's a no-brainer that the current behavior, which may cause multi-second delays at boot time, is wrong; but I think we still need to be setting the configured apm policy at boot time
[12:21] <Keybuk> slangasek: "still" ?
[12:21] <Keybuk> we don't set that right now
[12:22] <Keybuk> the hdparm udev rule comes from the days where we had to futz with DMA settings and stuff
[12:22] <slangasek> hmm, we do, actually... though perhaps we only set it via /etc/init.d/acpi-support
[12:22] <Keybuk> obviously since libata, that isn't used
[12:22] <Keybuk> slangasek: I just grepped through that, couldn't find anything about hdparm
[12:22] <Keybuk> wing-commander /etc% grep -r hdparm init init.d acpi power pm
[12:22] <Keybuk> init.d/bootlogd:# X-Start-Before:    hostname keymap keyboard-setup procps pcmcia hwclock hwclockfirst hdparm hibernate-clean
[12:22] <pitti> tkamppeter: you can't do it by internet, since the purpose of this is to have physical evidence that the key creator is actually the one he pretends to be ("can't pull yourself out of the swamp")
[12:22] <Keybuk> --
[12:23] <slangasek> Keybuk: /etc/init.d/acpi-support calls /etc/acpi/power.sh calls pm-powersave calls /usr/lib/pm-utils/power.d/95hdparm-apm
[12:23] <tkamppeter> liw, you tell in the Debian bug report that you have reported your problems upstream. Did you get any answer from the upstream author?
[12:23] <Keybuk> ahh
[12:23] <Keybuk> slangasek: got you
[12:23] <liw> tkamppeter, not yet
[12:23] <pitti> tkamppeter: phone is better, but not as trustworthy than seeing someone in an office, with a passport, etc.
[12:23] <directhex> slangasek, nope, doesn't look that way. remind me to check next time the sync run happens
[12:23] <Keybuk> slangasek: is that one of our scripts, or an upstream one?
[12:24] <slangasek> Keybuk: dunno offhand; can check
[12:24] <Keybuk> slangasek: you were thinking we should do that by calling out to hdparm on the drive in a udev rule instead?
[12:25] <slangasek> Keybuk: now as for the current udev script not doing apm settings... it applies any settings the user has configured in /etc/hdparm.conf, including apm and spindown, and nothing else does this by default
[12:25] <slangasek> (granted, that's not where we configure the system default apm settings, so yes, by default that part is a no-op)
[12:26] <tkamppeter> pitti: The problem with a key at the LF is that this could imply that the LF would take responsability on the manufacturer's driver packages.
[12:27] <pitti> tkamppeter: if the manufacturer has a working SSL certificate, they might also put the key and fingerprint on their web page (with https); that might actually work better
[12:27] <pitti> tkamppeter: as I said, trusting a key and trusting a package are completely independent
[12:27] <slangasek> Keybuk: the point I think we want to get to is that there's a single call to hdparm for each drive at the very end of the init sequence for any drives then available, and a udev rule that picks up any drives added after
[12:28] <pitti> tkamppeter: just because I am convinced that a key that says "Joe Sixpack" really belongs to a physical person "Joe Sixpack" does not mean that I trust any of his actions :)
[12:28] <tkamppeter> Working SSL certificate meas that their site is trusted by some certification authority?
[12:28] <liw> tkamppeter, I need to leave now; when you have time, if you can check the Debian bug I referred to for the ptouch-driver package, that would be most helpful, thanks
[12:28] <pitti> tkamppeter: yes
[12:28] <slangasek> that would mitigate the effects of hdparm on boot performance
[12:28] <pitti> the chain has to start somewhere with a physical identity proof
[12:28] <slangasek> (and if the udev rule itself is doing things that are inappropriate, we can fix that along the way)
[12:29] <tkamppeter> pitti, will that be enough to trust the manufacturer's keys when they come from this site with SSL certificate via https?
[12:29] <Keybuk> slangasek: it's not the effect of hdparm I care about
[12:29] <Keybuk> just the unconditional sync in the existing rule ;)
[12:30] <pitti> tkamppeter: well, "enough" is a matter of taste, but I think for these purposes yes
[12:30] <Keybuk> udev doesn'tre
[12:30] <pitti> tkamppeter: since otherwise people would download them directly from their web site, which involves the same trust (SSL cert)
[12:30] <Keybuk> udev doesn't really work in a "don't do it during boot but do it later" kind of way
[12:30] <Keybuk> frankly even upstart doesn't have a "very end of the init sequence" kinda thing
[12:30] <Keybuk> wouldn't it be better to do the hdparm calls for each drive from udev
[12:30] <slangasek> Keybuk: right; I don't understand why that unconditional sync is there, but the effect is obvious
[12:30] <Keybuk> including setting user settings and apm settings?
[12:31] <Keybuk> that way you get a single hdparm call per drive
[12:31] <Keybuk> which is called before the drive is actually used
[12:32] <slangasek> Keybuk: well, <cough> users with /usr on a separate partition aren't guaranteed to have the on_ac_power command available when the udev rule runs, so we would still have to re-apply the correct apm setting later
[12:32] <Keybuk> slangasek: is that the thing in /usr/bin that only looks in /proc and /sys ? :p
[12:32] <Keybuk> and is only in /usr because someone wrote it in awk
[12:32] <slangasek> heh
[12:33] <tkamppeter> pitti, so what I have to tell the manufacturers is to have an SSL certificate for their site from which the keys and packages should gget downloaded?
[12:33] <slangasek> it's also in /usr because it's not related to system recovery
[12:33] <Keybuk> would probably be better to fix *that*
[12:33] <Keybuk> since we already have the "can't call on_ac_power to decide whether to fsck /usr" thing :p
[12:33] <slangasek> yeah, that's a possibility
[12:33] <pitti> tkamppeter: well, either we need to sign their GPG key, or they must have an officially signed SSL cert and put the key/fingerprint on their website
[12:34] <tkamppeter> pitti, are there any requirements on where to place the keys relative to the packages so that the download tools find it?
[12:34] <slangasek> ok; so if we get on_ac_power in /bin where we can rely on it, then we can use the udev rule for all boot-time settings, and just arrange to make pm-powersave not call hdparm when invoked from init
[12:34] <pitti> tkamppeter: if the GPG keys have a proper signature, they should just be on the keyserver network
[12:34] <slangasek> and then remove that sync if we can confirm it's bogus
[12:34] <pitti> tkamppeter: if not, then we need to include them (in jockey or whereever)
[12:34] <slangasek> Keybuk: ^^ sound right?
[12:35] <Keybuk> slangasek: yup
[12:35] <slangasek> ok
[12:35] <slangasek> Keybuk: cheers :)
[12:35] <Keybuk> slangasek: the sync is almost certainly bogus in Ubuntu
[12:35] <Keybuk> I can imagine why it's there in Debian
[12:35] <Keybuk> (udev runs after things are mounted)
[12:35] <slangasek> hmm
[12:36] <Keybuk> I can't think of any way a udev rule could run on a mounted filesystem ;)
[12:36] <slangasek> why does udev run after things are mounted in Debian, either?
[12:36] <Keybuk> slangasek: I haven't looked at Debian in a while, but udev used to run very late
[12:37] <Keybuk> like after /usr was mounted
[12:37] <slangasek> /etc/rcS.d/S03udev
[12:37] <Keybuk> it wasn't always there though, right?
[12:37] <tkamppeter> pitti, what I now need to do is to put together some step-by-step instructions of generating keys, getting them signed or getting them onto an SSL-certified web site, what to provide to the download tools and where, ... Note for that that many manufacturers are not very Linux-aware.
[12:37] <Keybuk> the hdparm udev rule is old ;)
[12:37] <Keybuk> and converted from an even older init script
[12:38] <Keybuk> slangasek: ah
[12:38] <Keybuk> but S03udev just means udevd
[12:38] <slangasek> Keybuk: I don't see any record in the udev package of an init script migration
[12:38] <Keybuk> you could still have the block device appear later? even though it's already been mounted
[12:39] <Keybuk> slangasek: I'm only guessing :)
[12:39] <slangasek> hrm, how would it /get/ mounted in that case?  static device node?
[12:39] <slangasek> S03udev includes udevadm trigger/settle calls
[12:40] <Keybuk> maybe
[12:40] <slangasek> let me dig through the hdparm package, to see why this rule /really/ does what it does
[12:40] <Keybuk> at least we absolutely guarantee that we don't mount things until udev is done with them :p
[12:40] <Keybuk> slangasek: oh, I think it's always been there
[12:40]  * Keybuk wrote that script
[12:40] <slangasek> oh? :)
[12:40] <Keybuk> and it looks like I just copied that from the old init script
[12:40] <slangasek> odd, the changelog says thom wrote it
[12:41] <Keybuk> thom uploaded it
[12:41] <slangasek> ah
[12:41]  * Keybuk was on the Launchpad team at the time
[12:41] <Keybuk> (technically :p)
[12:42] <Keybuk> ahh
[12:42] <Keybuk> Vibe
[12:42] <Keybuk> that was a good UDS
[12:44] <slangasek> yeah, this -q -f goes all the way back to warty
[12:44] <slangasek> ahwell
[12:45] <Keybuk> slangasek: hole in the ground, with water in it
[12:46] <yoshi765> DAMN UBUNTU
[12:46] <Tm_T> !op | yoshi765
[12:46] <slangasek> yoshi765: not an appropriate use of this channel.
[12:46] <yoshi765> stfu
[12:47] <Hobbsee> clearly going to have a lot to say...
[12:48] <Tm_T> Hobbsee: shame this is one of the few channels I don't have rights ):
[12:48] <Hobbsee> heh :)
[12:49]  * Tm_T doesn't like just watch when there's some cleaning to do
[13:11] <amichair> pitti: when selecting to activate a driver in jockey, is there anything done that might take a long time? does it download anything? or it's supposed to be pretty much immediate?
[13:25] <pitti> amichair: sorry, was at lunch; yes, it will take a long time, which is why it spawns a progress dialog
[13:25] <pitti> it needs to download, unpack, install, etc.
[13:26] <amichair> pitti: ok, my test did a quick one so didn't see progress bar, and wondered if I should add one :-)
[13:27] <pitti> amichair: there should be one already; it works for me, anyway
[13:29] <amichair> pitti: ok, thanks
[13:31] <pitti> tkamppeter: instead of adding the "LogDebugHistory" to cupsd.conf in a patch, can you please just change the internal default? This will (1) keep the setting for admins who changed it, and (2) avoid a conffile change
[13:32] <pitti> tkamppeter: also, I think "2000" is a more reasonable limit than "999999" -- the latter would potentially result in a 100 MB log file
[13:42] <tkamppeter> pitti, I would leave the big value, as this makes the logging more or less unlimited. There should not be that many "DEBUG:" messages in the filters. Up to now in user-supplied error_logs in bug reports such an excess never happened.
[13:42] <tkamppeter> pitti, it is worse if some lines are missing in a user-supplied error_log.
[13:42] <pitti> but if they do, it'd be more or like a DoS of hard disk and bug trackers
[13:43] <pitti> well, but a million lines?
[13:43] <pitti> if there's something logging more than 1000 lines about an incident, this is certianly of questionable utility?
[13:43] <tkamppeter> A million lines is never reached. 10000 will perhaps happen.
[13:44] <pitti> so, let's make it 10000 then?
[13:44] <slangasek> Keybuk: hmm, the awk stuff is only used for PMU and APM... could just ignore this :-P
[13:45] <slangasek> Keybuk: do you happen to know if non-apci systems shoul also have /sys/class/power_supply/?
[13:45] <Keybuk> slangasek: they should
[13:45] <Keybuk> whether they do yet or not ...
[13:46] <Keybuk> *cry*
[13:46] <Keybuk> why is gdb skipping the entire body of the function when I do "n"
[13:46]  * Keybuk blames kees
[13:46] <slangasek> so I could move that block outside of the "if /sbin/acpi_available" check, and make the awk stuff Somebody Else's Problem
[13:47] <pitti> tkamppeter: FYI, I'm updating to 1.4.2 to grab the security fix
[13:47] <tkamppeter> pitti, I will add a fix to pdftopdf, got it from Otani-san today.
[13:49] <tkamppeter> pitti, you have reverted my last commit?
[13:49] <pitti> right
[13:53] <Keybuk> doko: around?
[13:54] <sladen> pitti: how should I poke apport to stop it reporting particular seahorse-agent crash dumps.  There's a couple of thousand dups to bug #429322 (to the point that it has broken LP) and more stack-trace uploads probably aren't really necessary
[13:54] <pitti> slangasek: there is an apport bug pattern for it since Tuesday or so
[13:54] <pitti> so it shouldn't even be possible to report further dups
[13:55] <pitti> (and yay for the bug which kept apport enabled after stable release :-( )
[13:56] <tkamppeter> pitti, pdftopdf fix from Otani-san is committed.
[13:56] <sladen> pitti: the dups are still arriving, or so that just the tracer catching up
[13:56] <doko> Keybuk: otp
[13:57] <pitti> sladen: retracers still have a huge backlog unfortunately
[13:57] <pitti> (for the same reason, swamped after final release)
[13:58] <Keybuk> doko: when you get back, gcc appears to have deleted the entire body of a function when compiling with -O0 ... how would I debug that ? ;p
[14:06] <maxb> james_w: Hi, are you around today? I was wondering if you could comment on bug 481097
[14:06] <doko> Keybuk: hmm, do you have a test case? when did this "optimization" start?
[14:13] <pitti> tkamppeter: btw, I'm going to do an upload now, but I fully expect that I have to do another one next week or so (new poppler in Debian didn't build yet everywhere, and I need to test it on mips again for the PIE issue)
[14:13] <pitti> tkamppeter: so, if you have other pending fixes they don't need to wait long
[14:13] <tkamppeter> pitti, I have also done the LogDebugHistory fix now.
[14:13] <pitti> ah, thanks
[14:13] <tkamppeter> Simply bzr pull and you have it.
[14:13]  * pitti cancels build and builds again
[14:20] <Keybuk> doko: s'ok, was a code error ;)
[14:20] <Keybuk> silly upsream
[14:20] <Keybuk> if (console->fd < 0);
[14:20] <Keybuk>   return
[14:20] <doko> heh
[15:03] <tkamppeter> pitti, can you help me on getting step-by-step instructions together for the manufacturers about generating keys, signing them or putting them on an SSL-certified site, signing the packages, so that users can easily get their drivers auto-downloaded?
[15:47] <theclaw> hi
[15:48] <theclaw> everytime firefox gets updated, the "quick search" entries get replaced/updated
[15:48] <theclaw> is this behaviour wanted?
[16:11] <dholbach> pitti: do you have access to robert_ancell's seahorse fix?
[16:12] <dholbach> pitti: there's like 3000 subscribers on the bug already
[16:12] <dholbach> mostly due to duplicates
[16:47] <pitti> tkamppeter: there's plenty of tutorials already; let's sit down next week and write/link something
[16:47] <pitti> dholbach: it should already be in karmic-proposed
[16:47] <pitti> dholbach: what do you mean with "access"?
[16:47] <dholbach> pitti: the bug is timing out in LP - good to know the fix is on its way :)
[16:48] <pitti> dholbach: yeah, took me like ten times to get the page, too :-(
[16:48] <pitti> mail responses FTW
[17:00] <Riddell> seb128: where did you upload the fix for bug 462049 to, lubic or -proposed?
[17:00] <Riddell> ..lucid
[17:01] <jussi01> Riddell: did you notice my comment about the links to kubuntu stuff on summit this morning?
[17:01] <Riddell> jussi01: nope, what was that?
[17:03] <seb128> Riddell, proposed we pocket copy then
[17:03] <jdong> lubic :)
[17:03] <seb128> Riddell, why?
[17:03] <jussi01> Riddell: just that the links on the summit calendar pages go to non-existant wiki pages when they should go to the corresponding LP pages...
[17:03] <Riddell> seb128: I just didn't see it in the queue, but there it is now
[17:03] <jussi01> Riddell: click on kubuntu lucid development here for instance: http://summit.ubuntu.com/uds-l/2009-11-16/
[17:04] <Riddell> jussi01: I have complained about this but I don't know if I complained to the right person and I probably didn't complain in the right way
[17:04] <jussi01> Riddell: ok, Ill go annoy jorge and jono about it
[17:05] <jussi01> Riddell: Ill try make sure it happens
[17:08] <Riddell> pitti: mind if I accept the SRU for bug 462049 into -proposed?  upstream are getting grumpy about it
[17:08] <mvo> do we have a wiki page that gives a step-by-step instruction how to do/trigger a fsck on the root fs?
[17:08]  * pitti adds "daily SRU round, take III" to his queue
[17:08] <pitti> Riddell: will do
[17:09] <jdong> hahaha
[17:09] <pitti> mvo: wouldn't tune2fs -C 50 /dev/... do?
[17:09] <pitti> that's what I usually do for testing
[17:09] <jussi01> !fsck
[17:09] <jussi01> mvo: ^^
[17:09] <mvo> pitti: this is similar to what I usually do, but I wonder if that is the way that we suggest to our users
[17:09] <pitti> mvo: well, I'd recommend -C 50; less dangerous to your data :)
[17:10] <pitti> mvo: oh, isn't it in friendly-recovery:
[17:10] <pitti> ?
[17:10] <mvo> jussi01: thanks
[17:10] <mvo> pitti: it used to until karmic, now its no longer possible to remount / in ro
[17:11] <jussi01> mvo: no probs :) If anyone comes across stuff in factoids that is out of date, please lets us know though.
[17:11] <mvo> pitti: this has to do with upstart changes, I talked to scott about it before the release and he said its intentional
[17:12] <Keybuk> mvo: it isn't anything to do with upstart
[17:13] <mvo> Keybuk: right, let me re-phrase it "it used to work by chance, now it does no longer" - better ?
[17:13] <Keybuk> :) much
[17:13] <mvo> :)
[17:13] <tkamppeter> pitti, OK, can you schedule a private meeting for that?
[17:14] <pitti> tkamppeter: no need to be private; I'll add it
[17:16] <mvo> Keybuk: hm, shutdown -F is ignored in the upstart code, is there a different magic to force it on restart?
[17:18] <mvo> Keybuk: nevermind, I think I found it
[17:18]  * mvo tries touch /forcefsck
[17:25] <tkamppeter> pitti, with private I meant an informal meeting, without Blueprint.
[18:50] <smoser> slangasek, ping.
[19:14] <Ademan> what should i do to find out about the new gdm/xsplash system?  I haven't run into anything from the simple greeter or xsplash that has any documentation...
[19:14] <Ademan> also while i'm at it... the upstart script for gdm has a seemingly magical variable $CONFIG_FILE, I don't see where that's ever set, is it set by upstart? how?
[19:45] <lamont> pitti: around?  your comment on bug 447919 is ref: lucid ,yes?
[19:55] <Ademan> does upstart set variables that are used in upstart scripts?  for instance the gdm upstart script uses $CONFIG_FILE which isn't set anywhere in the script that i can see.
[19:59] <StevenK> Ademan: I'm guessing that's set by X, but I can't find anything to back that up
[20:21] <Keybuk> cjwatson, StevenK: Remember that whole Cambridge, Plymouth, Dracut thing?
[20:21] <Keybuk> I have another one
[20:21] <Keybuk> Wayland
[20:24] <sebner> Keybuk: wayland \o/
[20:25] <StevenK> Keybuk: Haha
[21:33] <chrisccoulson> slangasek - i think i understand whats going on with your g-s-d crash now :)
[21:43] <chrisccoulson> and I think I can see why it regressed from jaunty too
[22:19] <lhasbs> ubuntu 9.04 server 2.6.28
[22:19] <lhasbs> massive group descriptor corruption :(
[22:19] <lhasbs> ext-4: group descriptors corrupted
[22:19] <lhasbs> Very strange and wierd here.
[23:00] <slangasek> smoser: pong
[23:00] <slangasek> chrisccoulson: oh?  Do tell!
[23:06] <chrisccoulson> slangasek - the section of your xtrace log i quoted in the bug report is all triggered from a single press of Fn+F7. what happens when you press this button is that the screen info is refreshed from the server (because the screen config changed when you connected the monitor). when the screen config changes, a handler in g-s-d autoconfigures the new output. It then acts on the Fn+F7 keypress to reconfigure the output again, wit
[23:06] <chrisccoulson> h screen information which is now out of date
[23:06] <slangasek> nice
[23:06] <slangasek> :)
[23:06] <chrisccoulson> it didn't crash in jaunty because g-s-d had no handler for auto-configuring new outputs
[23:07] <chrisccoulson> how soon after connecting the monitor do you press Fn+F7?
[23:07] <slangasek> chrisccoulson: well, ideally within seconds, I don't go to the effort of plugging in a cable I'm not using :)
[23:08] <slangasek> but I haven't noticed the monitor ever being autoconfigured for output, without me pressing Fn+F7
[23:09] <chrisccoulson> what i noticed from the xtrace log is that the Fn+F7 keypress arrives before the first RRScreenChangeNotify event, which should arrive when you connect the monitor
[23:10] <chrisccoulson> if you say that you've never seen the monitor being autoconfigured, then that would suggest that the RRScreenChangeNotify event doesn't arrive on it's own, and the xtrace log seems to support this
[23:10] <chrisccoulson> it only arrives after querying the configuration from the server :-/
[23:10]  * slangasek nods
[23:10] <chrisccoulson> and that is what seems to mess it up
[23:11] <chrisccoulson> so there might be a Xorg issue too
[23:11] <slangasek> sure
[23:11] <slangasek> though the g-s-d behavior seems to be racy per se
[23:12] <chrisccoulson> it does. normally the window of exposure should be small if the RRScreenChangeNotify event is delivered when you connect the monitor, but that doesn't seem to happen in your case
[23:13] <slangasek> yep
[23:13] <slangasek> (or in the case of other users who've reported this bug previously :)
[23:13] <chrisccoulson> is bryce around today?
[23:14] <chrisccoulson> ah, he's in #ubuntu-desktop
[23:15] <slangasek> right, he doesn't seem to really be around today though
[23:20] <chrisccoulson> slangasek - i'll add the rest of my thoughts to the bug shortly (so I don't forget them), and then try to get some input from bryce when he's around
[23:22] <chrisccoulson> slangasek - in the meantime, it might be good to run it through xtrace again, but watch the output in the console and see if you see the RRScreenChangeNotify event when you connect the monitor, or if it only appears after pressing Fn+F7 (just to confirm that I understand what is happening)
[23:22] <chrisccoulson> i don't know if you can make xtrace filter out specific messages or not
[23:46] <ebroder> MsMaco: ping?


[03:36] <plars> anyone here have a dell mini?
[13:49] <MekApels1n> persia: thx for the answer...
[19:58] <spacedog> i downloaded http://cdimage.ubuntu.com/releases/intrepid/release/ubuntu-8.10-umpc-i386.img
[19:58] <spacedog> it's a worthless peice of shit, coastered 2 cds
[20:00] <ogra> hmm, i would have helped him if he would have stayed a bit longer ... despite his language
[20:00]  * ogra shrugs
[20:19] <plars> ogra: no kidding
[20:19] <plars> would anyone here happen to have a dell mini running jaunty alphas?
[20:20] <ogra> i guess there are many people running the normal alpha ... probably not the mobile flavours atm though
[20:21] <ogra> (i know keybuk in #ubuntu-devel runs his bootspeed tests on a dell mini)
[20:21] <plars> I'm seeing some odd behaviour with sound recording... it comes out weak and choppy when I try to record sound though either the internal mic or an attached one
[20:21] <plars> just trying to determine if it's specific to the mini or other netbooks are also seeing this
[20:22] <lool> plars: You could check your hardware mixers with alsamixer
[20:23] <lool> Albeit it's probably a bug if you can only use that tool to do so
[20:30] <plars> lool: ah... I found a good combinations of settings that seems to work, thanks.  Not sure if alsamixer was the only way to do it, but it the defaults were certainly no good
[20:35] <plars> no, I guess I just got lucky one time... not working again