[00:10] <poolie> tjaalton, hi? bug 745112 seems to have regressed, can i do anything to help?
[00:17] <mwhudson> poolie: are you on oneiric?
[00:17] <poolie> yeah
[00:17] <poolie> it's intermittently very good
[00:17] <mwhudson> heh
[00:17] <poolie> i guess i should have asked in +1
[00:17] <mwhudson> i guess i should upgrade soon
[00:18] <poolie> however lack of reliable external monitor and suspend support is kind of annoying on a laptop
[00:18] <poolie> unity is getting distinctly useful
[00:18] <mwhudson> does unity itself work well with multiple monitors yet?
[00:18] <mwhudson> some times i would like not to have the laptop display off when using another monitor
[00:20] <poolie> i think tolerably well
[00:20] <poolie> i mostly find it too distracting and turn the internal one off
[00:21] <poolie> however it seems to be lacking a way to control where the dock/menubar go
[05:26] <pitti> Good morning
[05:27] <pitti> slangasek: yes, I recently demoted ubuntuone-couch/mocker because nothing kept it in main any more; but both have MIRs, so I re-promoted them
[05:27] <pitti> cnd: pkg-create-dbgsym itself can do it, but for regular PPAs there is no archive to publish them to
[05:28] <pitti> cnd: it's primarily an option for the OEM PPAs, which are non-virtualized and they have their own archive
[05:28] <slangasek> pitti: actually I repromoted them before you got to it ;)  (morning!)
[05:29] <ScottK> pitti: Getting dbgsym packages into a proper archive would be a good UDS topic I think.
[05:31] <pitti> doko_: yes, g-shell was uploaded, but dep-waiting on caribou; both are built now, and the remaining cogl2 rdepends are now fixed
[05:31] <pitti> slangasek: gdm/lightdm fix> no, go ahead; I guess you already did
[05:32] <slangasek> pitti: more or less... gdm is in, lightdm was caught up because robert_ancell has changes committed to trunk - I've branched around that now, needs someone to approve it in the queue :)
[05:32] <pitti> ScottK: not sure what's left to do there; LP supports it, IIRC the main thing there is that it is hard for LP to "forget" the obsolete ones
[05:33] <ScottK> If it was easy, you'd have done it already.....
[05:33] <pitti> but I'd be really happy to finally drop this nasty and brittle ddeb-retriever hack
[05:35] <superm1> when are the daily images going to be resumed again?
[05:35] <superm1> i had wanted to check and make sure that the changes I made post b2 didn't push mythbuntu back oversized again
[05:36] <pitti> superm1: they are on now
[05:36] <pitti> but no idea whether they were enabled ten minutes ago or on Friday
[05:36] <superm1> probably today, i haven't seen any livefs attempts from the weekend (http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/mythbuntu/)
[05:37] <superm1> i'll check tomorrow then, thanks pitti
[05:37] <ScottK> It was Sunday, FSVO Sunday.
[06:16] <tjaalton> poolie: hmm, maybe open a new bug for it, with a reference to the old one? also, please try 3.1rc mainline kernel if it's fixed there
[06:18] <poolie> ok tjaalton
[06:19] <poolie> tjaalton, is there a packaged 3.1rc?
[06:20] <tjaalton> poolie: sure, http://kernel.ubuntu.com/~kernel-ppa/mainline/
[06:42] <dholbach> good morning
[07:15] <micahg> pitti: does it make any sense to use dh --with apport and then override it later?
[07:17] <pitti> micahg: I think it does if you want to supply extra options
[07:17] <micahg> ok, great, that's what I want to do (needs a package name :))
[07:21] <tkamppeter> pitti, hi
[07:22] <pitti> hello tkamppeter
[07:22] <pitti> micahg: then you don't need to care about which other dh_* command to append it to, i. e. --with will take care of the correct ordering already
[07:22] <pitti> micahg: (not a biggie for dh_apport, but in general)
[07:23] <micahg> pitti: oh,  so I could toss it under override_dh_auto_install?
[07:23] <tkamppeter> pitti, it is about bug 787067, a GS crash on Apple-generated EPS files. Fix would be to not use the system-supplied liblcms1 any more but the Ghostscript-built-in one. Should I switch to that one then?
[07:23] <pitti> micahg: no, that's too early
[07:23] <pitti> micahg: override_dh_install perhaps
[07:24] <micahg> pitti: I just did override_dh_apport?
[07:24] <pitti> micahg: yes, that plus --with is correct
[07:24] <micahg> ok, great
[07:24] <pitti> tkamppeter: I'd rather avoid it; library duplication is EBW
[07:24] <pitti> tkamppeter: can't the fix be applied to liblcms1?
[07:24] <dholbach> lucas, bon anniversaire! :)
[07:25] <tkamppeter> pitti, the fix suggested here is downgrading to liblcms1_1.16-7ubuntu1
[07:26] <tkamppeter> pitti, we currently use 1.19.dfsg-1ubuntu1
[07:29] <tkamppeter> pitti, perhaps one can advance GS to liblcms2.
[07:30] <pitti> tkamppeter: it seems it's rather easy to reproduce the bug with a command line, so bisecting liblcms changes between 1.16 and 1.19 should be feasible; woudl be better to fix the regression for 1.19 than downgrading, IMHO
[07:45] <tkamppeter> pitti, quick check shows that building GS against lcms2 fixes the segfault, but GS upstream developers tell that lcms2 is too buggy and not recommended to be used with GS ...
[07:57] <brendand> does anyone know if there's been a change in glade (or gtk) such that the __init__ function of custom components written in python wouldn't get called? i've been hit by this since just a few days ago (friday)
[07:58] <pitti> brendand: bug 856669
[07:58] <pitti> brendand: I'm working on it right now
[07:58] <brendand> pitti - brilliant! great to know it's a known issue
[07:58] <lucas> dholbach: thanks :)
[08:14] <pitti> brendand: fix uploaded, FYI
[08:15] <brendand> pitti - cool. thanks
[08:19] <AlanBell> ev: can we discuss bug 781385
[08:58] <Sweetshark> Moin desktoppers!
[09:01] <jibel> mvo, morning, could you look at 854090 ?
[09:01] <mvo> jibel: sure!
[09:01] <jibel> bug 854090
[09:02] <mvo> jibel: did you (or someone else) actually managed to reproduce this one?
[09:03] <jibel> jibel, not yet, I just saw the high number of recent duplicates.
[09:10] <ev> AlanBell: sure can, though I've followed up on the bug.
[09:11] <didrocks> mvo: I didn't manage to reproduce it, just seeing a lot of people getting it using oneconf for instance (which just get the list of installed package)
[09:11] <mvo> didrocks: oh, thats interessting
[09:12] <didrocks> mvo: the only part using apt is http://paste.ubuntu.com/697154/ FYI
[09:12] <didrocks> not sure if this can help
[09:14] <mvo> ok
[09:16] <SrPiojos> good morning
[09:16] <AlanBell> thanks ev
[09:16] <ev> sure thing
[09:16] <SrPiojos> I am in the process of designing a forum for Ubuntu Developers in Mexico
[09:17] <SrPiojos> and I need advice as to which of these four logos on this montage
[09:17] <SrPiojos> would look that best
[09:17] <SrPiojos> http://i.imgur.com/Usqtb.jpg
[09:36] <ochosi> chrisccoulson: ping
[09:41] <tkamppeter> pitti, I am trying to get a stack trace from liblcms, I have rebuilt the package locally and then manually copied the unstripped version of the lib into its place in the system, bug gdb says warning: Can't read pathname for load map: Input/output error. and does not load the symbols of liblcms. Is there a special trick for multiarch?
[09:43] <pitti> tkamppeter: the warning happens everytime, that's normal
[09:44] <tkamppeter> pitti, any idea why I do not get the symbols? I have checked the lib with "file" and it is really unstripped.
[09:45] <pitti> tkamppeter: did you copy it to the same place as the original package?
[09:45] <pitti> tkamppeter: if so, then I have no idea
[09:51] <OdyX> pitti, tkamppeter: do you have opinions about http://bugs.debian.org/641687 ? (aka "impossible to setup a printing driver without colord installed" )?
[09:53] <tkamppeter> pitti, I did, /usr/lib/x86_64-linux-gnu/
[09:59] <AlanBell> ev: is there a way to run ubiquity from trunk, I only know how to start it from the live CD
[10:00] <lag> My desktop just randomly shut itself down
[10:00] <ev> AlanBell: you can build it using debuild then copy the resulting ubiquity-frontend-gtk, ubiquity, and ubiquity-ubuntu-artwork debs into a live CD
[10:01] <tkamppeter> pitti, on #ghostscript I got told that libcms1 is not maintained upstream any more and therefore the GS deveklopers have applied fixes to their own version and did not report them upstream. They also tell that therefore in GS 9.05 they want to remove the possibility to use the system liblcms(1). Seems that for P we need to switch GS to liblcms2 and use the time of the cycle to test and find bugs. WDYT is best for Oneiric then?
[10:01] <lag> I've looked in /var/log/[kernel.log&syslog], but there's no clues in there as to what went wrong
[10:01] <AlanBell> ok, not much easier than just booting the CD and poking at the files there
[10:01] <ev> AlanBell:  indeed, that
[10:01] <ev> s generally much quicker
[10:01] <AlanBell> lag: probably temperature
[10:01] <tkamppeter> pitti, Upstream GS suggests to use GS' own lcms1 for the current Ubuntu release.
[10:01] <lag> AlanBell: Does Ubuntu log such things?
[10:02] <pitti> tkamppeter: could we at least bisect the changes and check which one caused the regression?
[10:02] <lag> AlanBell: Surely there would be something in the logs "over-temp warning, shutting down..."
[10:02] <pitti> tkamppeter: duplicating libraries is a pain, and downgrading gs' one to a previous version will presumably re-open color management bugs again which were fixed since then?
[10:03] <AlanBell> lag: yes, in syslog normally I think. It is the main thing I know of that causes a controlled suicide shutdown -h now
[10:03] <lag> AlanBell: I don't see anything
[10:03]  * lag installs sensors-applet 
[10:07] <tkamppeter> pitti upstream suggests duplicating the lcms1. They want to stabilize the lcms2 shared library use for the next cycle (9.05).
[10:08] <tkamppeter> pitti, I have diffed the upstram source of liblcms1 with the source coming with GS and the diff of the src/*.c is huge.
[10:08] <tkamppeter> pitti, bisecting does not work, there is VCS for libcms1.
[10:09] <pitti> "no VCS"?
[10:09] <tkamppeter> pitti, seems that we have to duplicate the lcms1 to overcome the time until getting the real solution in GS 9.05.
[10:09] <pitti> tkamppeter: can we disable color management support in gs for oneiric, if it's not ready yet and crashy?
[10:10] <tkamppeter> pitti, the VCS on LittleCMS.com is a GIT started in 2010 with only libcms2.
[10:10] <cjwatson> lots of upstreams suggest duplicating libraries; if they were all correct then distributions would be considerably larger and considerably less secure :-)
[10:11] <tkamppeter> pitti, I do not really know whether it is possible in GS 9.0x, as CMS is deeply integrated there. It can perhaps cause more crashes at other places.
[10:13] <tkamppeter> pitti, only crash point in GS for now are these Apple-generated EPS files, so most of CMS is stable. Switching to the GS-internal lcms1 would make also this point stable and we would ship a GS without known crashes.
[10:14] <tkamppeter> pitti, security responsability of this code piece will be taken by GS upstream.
[10:15] <pitti> tkamppeter: it might fix this bug, but how many others would it reopen?
[10:15] <tkamppeter> pitti, and it is also only for one non-LTS cycle.
[10:15] <pitti> all the changes between 1.16 and 1.19 weren't made in vain, I suppose :)
[10:16] <tkamppeter> pitti, the one in GS is the new one, not 1.16.
[10:17] <pitti> tkamppeter: I thought you said it only worked with 1.16, so I thought that's the version gs ships with
[10:17] <pitti> if it also ships with 1.19, then the diff can't possibly be so large?
[10:17] <pitti> or did they do so heavy modifications to the internal copy?
[10:17] <pitti> (if so, it's all the more reason to disable it completely -- this kind of behaviour is simply unacceptable)
[10:22] <tkamppeter> pitti, the diff is really big: 15 files changed, 1050 insertions(+), 905 deletions(-)
[10:26] <pitti> tkamppeter: so I suppose the included version isn't 1.19?
[10:27] <tkamppeter> pitti, I have diffed the included version against 1.18 and 1.19. The diffstats look nearly equal. This means that the changes the GS developers did are much, much bigger than the changes between 1.18 and 1.19
[10:29] <tkamppeter> pitti, 1.18 -> 1.19: 4 files changed, 10 insertions(+), 7 deletions(-)
[10:29] <tkamppeter> pitti, additional remark: I tried also to install 1.16 (originally suggested workaround) but GS crashes with it for me, too.
[10:31] <pitti> so that also means gs' internal copy is a totally homebrew one, and hasn't been tested at all so far with other printing related things
[10:31] <pitti> that makes me even less confident that switching to the internal version is a good idea at this point ..
[10:31] <directhex> mvo, how does apt's new netrc support deal with passwords containing spaces?
[10:35] <tkamppeter> pitti, the internal lcms was tested by the regression tests of GS upstream which they do after every GIT commit and these tests run 1000s of files through GS, there are even tests with the CUPS Raster output device.
[10:37] <pitti> tkamppeter: and we know that their version works with our packaged version of colord, gnome-color-manager, etc? we never tested it in any real "print this document" test case in oneiric
[10:43] <tkamppeter> pitti, perhaps leaving this bug unfixed and providing a personal solution (PPA), for example a GS build using libcms2 to this one user who complained, and putting O and P tasks to the bug, marking O "Won't fix", as it is too close to release and the available fixes are too big changes.
[10:43] <pitti> tkamppeter: works for me
[10:45] <tkamppeter> pitti, I will also use this LCMS2-based GS on my systems to keep it under observation and also upload it to P as soon as P opens, so that it gets tested. If it turns out to be stable I will propose it as SRU in 2 months or so.
[11:08] <janimo> ScottK, hi, around? Why is the build log necessary for the glmark2 FFE? Also the detailed description of testing? The one requesting the FFE and the packager is the upstream author as well
[11:09] <ScottK> Because those are normal things required for an FFe.
[11:09] <janimo> build log? hmm, never saw that asked for honestly.
[11:11] <tkamppeter> pitti, OdyX wants an opinion about debian bug 641687, should we make cups depend on colord here?
[11:11] <pitti> tkamppeter: that sounds unsuitable for Debian at least; we can't easily make it work without colord support?
[11:12] <pitti> OdyX: ^ cups is also used in embedded environments, so adding a hard dependency on colord seems a bit exaggerated?
[11:13] <OdyX> pitti: I would tend to agree, yes. colord doesn't sound essential to cups' core task, so wouldn't justify a hard depends. IMHO, eh.
[11:13] <mvo> directhex: space should work fine, the tokenizer uses \n\t as tokens
[11:14] <mvo> directhex: eh, as delimit
[11:15] <directhex> netrc(5) says spaces as well. which is the issue
[11:15] <directhex> the python netrc library implies you can't use spaces in netrc, too
[11:16] <tkamppeter> pitti, so the colord patch of CUPS needs a fix to fall back to non-CMS if colord is absent. Is this only relevant for Debian or should we do this fix also for Oneiric?
[11:16] <tkamppeter> OdyX, ^
[11:17] <OdyX> If colord is also a recommends of cups in oneiric, I'd say it should be done in both.
[11:17] <mvo> directhex: hm, I don't know about the python one, but at least from looking ah the apt code (and curl) it should work, but I did not actually test it, so I may be wrong
[11:17] <pitti> tkamppeter: seems relevant for both
[11:51] <tkamppeter> pitti, next problem: bug 850680, some packages' postinstall scripts return error status 10. Do you have any idea? The treminal logs do not show anything useful.
[11:58] <cjwatson> tkamppeter: DEBCONF_DEBUG=developer
[11:59] <Daviey> Can an archive admin reject cobbler-enrol (source) NEW package please, been superseeded with cobbler-enlist.  Thanks :)
[11:59] <cjwatson> tkamppeter: error 10 is typically debconf's "bad parameters" error, indicating incorrect use of debconf
[11:59] <cjwatson> tkamppeter: the above environment variable should let you track it down
[12:00] <cjwatson> it's generally, though not exclusively, an attempt to use a question name that doesn't exist
[12:03] <tkamppeter> cjwatson, strange is that I never changed this debconf stuff and that only one user complained and not 100s.
[12:03] <cjwatson> tkamppeter: it could easily be conditional code or similar.  It needs investigation rather than either of us guessing ...
[12:04] <tkamppeter> cjwatson, perhaps I have to ask the user to run the scripts manually with DEBCONF_DEBUG=developer.
[12:05] <tkamppeter> pitti, I have a problem with upload to my PPA. Half an hour ago it worked, now I get
[12:05] <tkamppeter> Changes file must be signed with a valid GPG signature: Verification failed 3 times: ['General error', 'General error', 'General error'] : Permission denied.
[12:05] <tkamppeter> Note: This error might indicate a problem with your passive_ftp setting.
[12:05] <tkamppeter>       Please consult dput.cf(5) for details on this configuration option.
[12:06] <cjwatson> tkamppeter: yes, that is roughly what I'm suggesting.  But don't ask them to run the scripts manually, as it's too easy to get the arguments wrong; try 'DEBCONF_DEBUG=developer dpkg --configure -a' instead
[12:06] <cjwatson> (assuming they haven't already destroyed the evidence, which is quite possible)
[12:06] <cjwatson> tkamppeter: upload> wait a bit and check whether the upload actually succeeded anyway.  This is a known problem
[12:06] <tkamppeter> cjwatson, in that case I will close the bug as invalid. Thanks.
[12:07] <cjwatson> tkamppeter: well, not until after investigation :)
[12:07] <tkamppeter> cjwatson, Upload actually arrived and is happily building.
[12:16] <pitti> tkamppeter: sorry, was at lunch; but seems cjwatson already answered, thanks
[12:18] <tkamppeter> cjwatson, piiti, bug 850680 updated.
[12:19] <cjwatson> tkamppeter: I know man-db is correct here (audited carefully multiple times); anything like that biting it is a problem in whichever higher-level package manager is in use - so it's worth also finding out which package management frontend they're using
[12:22] <tkamppeter> cjwatson, for me it also looks like that this is not a bug of the individual packages as ate least on cups and foomatic-filters the debconf stuff did not get touched for longer time. The package manager frontend seems to be a good candidate here.
[12:26] <mvo> @pilot in
[12:30] <tkamppeter> pitti, I am trying to build GS with liblcms2 on my PPA, all builds fine but d-shlibmove fails: http://paste.ubuntu.com/697232/ How can I fix this?
[12:31] <tkamppeter> pitti, build-depends is liblcms2-dev, I wonder why this debhelper wants to have liblcms2-2-dev.
[12:32] <pitti> tkamppeter: I'm afraid I never used or even heard of d-shlibmove :/
[12:33] <pitti> tkamppeter: perhaps there's an option to tell it that liblcms2-dev is the correct one?
[12:35] <tkamppeter> pitti, it already uses --ignorelibdep
[12:38] <tkamppeter> pitti, seems that only solution ius that I also make a PPA version of libcms2, providing liblcms2-2-dev in addition, as liblcms2-dev is a non-standard.
[12:39] <pitti> tkamppeter: liblcms2-dev is a standard name
[12:39] <tkamppeter> pitti, so the bug is in d-shlibmove and/or using d-shlibmove is a non-standard.
[12:40] <pitti> right, or the invocation of d-shlibmove needs to be updated for lcms2
[12:52] <didrocks> mvo: thanks for the apt fix!
[13:08] <xranby> hi i would like to package a Upstart script that enables zram swap on bootup  for low ram systems such as the ac100 laptop. any pointers where to begin?  create a package and upload it to a private ppa?
[13:08] <xranby> i have currently only uploaded the script to https://wiki.ubuntu.com/ARM/TEGRA/AC100?action=AttachFile&do=view&target=zramswap.conf
[13:09] <xranby> it are based on the script provided from http://weirdfellow.wordpress.com/2011/05/04/compressed-ram-with-zram/   and altered to only allicate half of available ram for zram http://weirdfellow.wordpress.com/2011/05/04/compressed-ram-with-zram/
[13:25] <mterry> @pilot in
[13:29] <mterry> mvo, hi!  we're both pilots, which stuff are you doing, so I can avoid it?
[13:30] <mvo> mterry: I can take a pilot break now, I just got a s-c bug assigned so that should be fine
[13:30] <mvo> @pilot out
[13:30] <mterry> mvo, OK, happy bug squashing!
[13:37] <mvo> thnx
[13:42] <stgraber> SpamapS: hey! can you have a look at bug 856810? I doubt it's related to netcfg of lightdm but looks like related to these upstart network jobs changing recently
[13:50] <pitti> doko: eglibc> where does the huge delta in locale/C-translit.h come from? (not from a patch, inline change)
[13:50] <doko> pitti, it's a generated file, does get built for every build. you can ignore it
[13:50] <pitti> ok
[14:00] <jdstrand> mvo: hey, fyi - it seems that we have another 'apt-get source' bug (859665)
[14:03] <dobey> cjwatson: ping; can you actually upload lp:ubuntu/ubuntuone-control-panel to the archive? seems you merged a fix in a couple weeks ago, but it hasn't actually been uploaded to archive?
[14:05] <cjwatson> dobey: I did (as patch pilot), but it was typographical, so there was no reason to upload right away; it was fine for it to wait until somebody had a better reason for an upload
[14:05] <cjwatson> part of the point of using branches is that we don't need to upload on every change :-)
[14:05] <dobey> oh ok
[14:10] <mvo> thanks jdstrand - I check it out
[14:11] <hunger> Are you guys still in the plan wrt. the oneiric release?
[14:30] <cjwatson> hunger: I'm not sure what your question means - could you elaborate?
[14:31] <hunger> cjwatson: Just wondering whether the release might be post-poned.
[14:32] <ogra_> up to beta2 we were in the plan at least :)
[14:32] <cjwatson> hunger: I know of no reason why it would be, at the moment.  Why do you ask?
[14:32] <hunger> Just tried the beta 2 and that made me wonder. Never have seen such a buggy beta release of you guys yet.
[14:33] <cjwatson> Thankss.
[14:34] <ogra_> hunger, you just test the wrong architecture ... use arm... compared to natty the beta is 33.2% less buggy :)
[14:34] <hunger> cjwatson: Sorry. All the betas of previous releases were rather solid. Oneiric is the first I had to remove again since it is plain unusable.
[14:35] <cjwatson> Well, it's not the most productive way to put it.  It's a rather big distribution and you provide no particular indication of which bits are problematic.
[14:35] <cjwatson> (And in any case this is not the right forum for that, unless you have fixes)
[14:36] <hunger> cjwatson: Shutdown not working anymore, random screen freezes, menu not showing up for some apps at all, that gear thing on the far left vanishing randomly.
[14:37] <hunger> cjwatson: ... window manager having to restart, unity dash not opening after a while, ...
[14:37] <ogra_> did you file bugs for all these issues ?
[14:37] <hunger> cjwatson: And all that on a run-of-the-mill netbook HW.
[14:37] <hunger> ogra_: Not yet.
[14:38] <seb128> half of those are known and being worked
[14:38] <hunger> seb128: Good:-)
[14:38] <seb128> bug #854292
[14:38] <seb128> that's the "gear" one
[14:38]  * cjwatson has nothing to do with any of those.  I guess I'll go back to introducing^Wfixing bugs somewhere else.
[14:38] <seb128> is shutdown not working from the login screen?
[14:39] <hunger> seb128: Not even shutdown -h now works:-(
[14:39] <seb128> ok, dunno then
[14:40]  * hunger should probably just file bug reports and shut up to not keep you guys from fixing bugs.
[14:41] <hunger> seb128: bug #854292 is not the one I am seeing. I did not run apt-get or anything.
[14:41] <seb128> hunger, you didn't use update-manager?
[14:42] <seb128> hunger, well it's most likely the same issue but maybe triggered a different way
[14:42] <hunger> seb128: I got the CD and installed that. Logged in and played a bit, starting apps, etc.
[14:42] <hunger> seb128: I did not update... did not notice any updater poping up either.
[14:43] <seb128> hunger, well maybe it has nothing to do with updates, updates seemed something that come often close from the issue
[14:43] <seb128> hunger, but anyway likely the same bug as I said, it might just happen under different conditions
[14:44] <hunger> seb128: Great. One bug less for me to file:-)
[14:45] <cjwatson> hunger: it's not so much keeping us from fixing bugs, but that "your work sucks" is pretty demotivating.
[14:45] <cjwatson> Constructive contributions are way better, and welcomed
[14:46] <hunger> cjwatson: Sorry.
[14:48] <hunger> cjwatson: unity is turning out rather nice in oneiric.
[14:50]  * cjwatson has nothing to do with unity, for the avoidance of doubt
[14:50] <hunger> cjwatson: Just wanted to say something positive, too:-)
[14:51] <cjwatson> I'm not asking for praise either; by constructive I mean helping out with the problems
[14:54] <tkamppeter> pitti, I have a solution for the GS/lcms2 problem: I am removing d-shlibmove. d-shlibmove seems to be rarely used. Only GS and jbig2dec are the d-shlibmove-using packages from the ones whose source I have on my laptop.
[14:55] <hunger> cjwatson: I understand that position, but it is rather hard to debug all this stuff. I can file bug reports, but that is where it ends for me.
[14:57] <OdyX> hunger: filing useful bugs (with as much information as possible, reproducing-steps, precise description of what fails for you) _is_ important.
[15:00] <hunger> OdyX: I know. But I don't think I can provide reproducing steps, etc. :-(
[15:03] <tseliot> pitti: did you see my message about bug #855396 (which is not fixed yet, despite our work)?
[15:06] <jono> seb128, didrocks quick q: have you come across a bug where USB devices (e.g. webcams, headsets) don't appear in the sound settings capplet seemingly after a suspend?
[15:06] <seb128> jono, I didn't
[15:07] <jono> seb128, ok I will file a bug
[15:07] <seb128> jono, seems like a pulseaudio issue
[15:07] <jono> seb128, yup, lsusb sees the devices
[15:07] <jono> I will file it against pulse
[15:07] <didrocks> jono: I didn't as well
[15:07] <jono> thanks guys
[15:07] <jono> will file it soon, on a call now
[15:08] <didrocks> sure, thanks :)
[15:08] <seb128> jono, try asking diwic about it
[15:08] <jono> seb128, will do
[15:11] <pitti> tseliot: ah, thanks; reopening then
[15:12] <pitti> will have a look
[15:12] <tseliot> pitti: thanks (I've also added a log)
[15:19] <SpamapS> stgraber: ack, looking now
[15:22] <SpamapS> stgraber: at the point where that message is displayed, the system is pretty much guaranteed to enter runlevel 2.. so its a bit of a red herring that this message is showing when other things fail to come up.
[15:32] <SpamapS> Hmm... lightdm stop son runlevel [016] , but also starts on runlevel [!06]
[16:24] <jdstrand> bdmurray: fyi, mvo said he was looking at 859665
[16:24] <jdstrand> bdmurray: but I still responded to your question
[16:25] <bdmurray> jdstrand: okay thanks
[17:27] <slangasek> apw: does bug #855764 make sense to you at this point?  Is there anything you would like me to test to help narrow this down?
[17:35] <mterry> @pilot out
[17:43] <slangasek> smoser: hah, so the udevadm settle had *no* effect on finding /dev/console?
[17:44] <smoser> well, 0/329 for control
[17:44] <smoser> 0/500+ for udevadm settle
[17:44] <smoser> so unable to get any real data.
[17:45] <slangasek> smoser: but then 1/1 on each when you ran it on a different cloud?
[17:45] <smoser> but its all just racy. depends on cpu to disk speed ratio.
[17:45] <smoser> right.
[17:45] <smoser> i can setup tests on the cloud where we get hits and try again.
[17:47] <slangasek> smoser: in that case, can I ask you to modify /init in the initramfs to check for ${rootmnt}/dev/console existence right before calling run-init, and if it's missing, to dump /dev/.udev.log to the terminal?
[17:47] <slangasek> I'd like to see what it is udev is doing
[17:48] <smoser> yeah. i can do that. just modify that intiramfs a little more.
[17:48] <smoser> what i did previously was just take the one image and publish a "pure beta-2"
[17:48] <smoser> then i mounted fs loopback and just re-packed the existing initramfs and put it back into the image and published the modified
[17:48] <smoser> so the only file different in the 2 images was the initramfs
[17:49] <smoser> so... i will try to get some runs with that. on the reproducing cloud.
[18:27] <SpamapS> Hrm, so I'm having trouble with dh_python2 ..
[18:28] <SpamapS> When there's only one package in debian/control .. it automatically just shoves all of debian/tmp into the package..
[18:28] <SpamapS> but when there are two.. its not putting the python modules anywhere..
[18:28] <tumbleweed> that's not dh_python2's job
[18:28] <SpamapS> oh, it scans the packages after?
[18:28] <SpamapS> that makes sense actually.. good point
[18:28] <tumbleweed> yes
[18:28] <tumbleweed> also normally when there's only one package, there is no debian/tmp
[18:29] <SpamapS> right, there isn't.. it all makes sense now
[18:30] <SpamapS> was over thinking the problem entirely
[18:30] <tumbleweed> :)
[19:06] <crass> what's the right channel for getting help with a packaging issue for my personal ppa?
[19:06] <nigelb> Probably #ubuntu-packaging
[19:06] <crass> ok, thanks
[19:16] <lynxman> SpamapS: ping
[20:00] <SpamapS> lynxman: pong, sup?
[20:02] <lynxman> SpamapS: hey sorry to bother you, any idea what we're doing about rabbitmq for oneiric? Are we pushing to 2.6.0? Just wondering because I'm maintaining rabbitmq-stomp and rabbitmq-erlang-client and they'll need updating too
[20:03] <SpamapS> lynxman: its way too late for that I'm afraid. :-/
[20:03] <SpamapS> lynxman: if I had been able to jump on it right away it might have gotten done, but that was a month ago. :(
[20:03] <lynxman> SpamapS: cool, no problem at all, was just wondering
[20:03] <lynxman> SpamapS: since there was a bit of conclicting info in the sprint :)
[20:04] <lynxman> SpamapS: thanks for the clarification ;)
[20:05] <lynxman> SpamapS: also if you want I can do 2.6.0 myself and push it in a ppa or something, got used to it
[20:05] <SpamapS> lynxman: have the debian maintainers shown any movement on it?
[20:05] <lynxman> SpamapS: fraid not
[20:05] <lynxman> SpamapS: I can do it and push it back to them though
[20:06] <lynxman> SpamapS: since I'm already trying to push rabbitmq-stomp and rabbitmq-erlang-client back to debian anyway
[20:06] <SpamapS> lynxman: ok, thats fine.. sounds like we should move forward with 2.6.0 in a PPA and maybe help them out if they get stuck with it.
[20:07] <SpamapS> lynxman: ideally you'd maintain them in Debian.. :)
[20:07] <lynxman> SpamapS: heh, I'm trying for mcollective but since I'm unknown in Debian... :)
[20:09] <SpamapS> lynxman: this is precisely how you get known in Debian.
[20:09] <lynxman> SpamapS: I'll ask for some guidance for that then, let me try first to iron out the 2.6.0 properly :)
[20:12] <smoser> slangasek, i was reading back above
[20:12] <smoser>  "can I ask you to modify /init in the initramfs to check for ${rootmnt}/dev/console existence right before calling run-init, and if it's missing, to dump /dev/.udev.log"
[20:13] <smoser> i'm guessing you want to back out the udevadm settle,t hen, right ?
[20:13] <smoser> and basically just panic with more debug
[20:13] <slangasek> smoser: I'd like to see it with both bits present
[20:13] <smoser> hm... but you're very much less likely to see the udev debug if we add the udevadm settle, no ?
[20:14] <smoser> and possibly that would "fix" our issue, meaning you'd *never* see that debug output
[20:14] <slangasek> smoser: I was assuming you'd run this on the system where you got 1 for 1 on failures
[20:14] <smoser> well, its not completely 1x1, but its closer.
[20:15] <smoser> but my argument is still that the udev.initramfs-bottom change will make us not hit the udev debug stuff.
[20:17] <slangasek> smoser: oh, I misread your last comment in bug #833783 - I thought you had said running on CanoniStack, you saw the error both with *and* without the udevadm settle change
[20:17] <smoser> i was not able to add the image on canonistack. i've only ever seen it on the control there.
[20:18] <slangasek> smoser: ok, so testing this fix on CanoniStack is impractical?
[20:18] <smoser> no i think its reasonable. we can test it there.
[20:18] <smoser> the only reason i did not is that ther eis a bug that means i have to tap someone in IS's shoulder every time i upload an image
[20:19] <smoser> (bug 845788 bug 851059 are fixed now, but they're on older version)
[20:20] <smoser> and fwiw, i'm pretty sure that the change that made me *not* see it on my developer system was bug 837100 being fixed.
[20:21] <slangasek> smoser: I would appreciate it if you could test the proposed fix on CanoniStack; I don't want to push the change without some evidence that it makes things better, and so far we don't have any evidence of that
[20:22] <smoser> ok. i'll test there.
[20:56] <kirkland> cjwatson: howdy!  how do we actually take advantage of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605614 ?
[20:56] <kirkland> cjwatson: ie, how/where do we pass the installing guest the hostname of the rsyslog server?
[20:57] <kirkland> cjwatson: in a preseed or a kernel cmdline?
[20:59] <cjwatson> kirkland: it's been in Ubuntu for years ...
[20:59] <cjwatson> kirkland: log_host= and log_port= on the kernel command line
[20:59] <kirkland> cjwatson: perfect, thanks!
[21:00] <cjwatson> log_port is optional, it defaults to whatever the default syslog port is (I forget)
[21:00] <kirkland> cjwatson: np
[21:03] <micahg> I assume Bug #859223  should be won't fix?
[21:04] <slangasek> micahg: definitely
[21:22] <cnd> I upgraded a natty machine to oneiric, and I no longer have a "classic" mode option at login
[21:22] <cnd> how do I get that back?
[21:23] <jtaylor> there is no classic anymore, only gnome3 unity xfce and lubuntu (openbox + something)
[21:23] <cnd> ok
[21:23] <bryceh> cnd, install gnome-panel
[21:25] <seb128> or gnome-session-fallback
[21:26] <cnd> bryceh, gnome-panel worked
[21:26] <cnd> thanks!
[22:00] <Sweetshark> jasoncwarner_: ping?
[22:17] <jasoncwarner_> Sweetshark: hey!
[22:17] <Sweetshark> Ho!