[21:56] <BobJonkman1> Egg Roll King is confirmed for Victoribuntu Hour on Monday, 19 May 2014 at 6:00pm http://loco.ubuntu.com/events/ubuntu-ca/2809/detail/


[00:42] -queuebot:#ubuntu-release- Unapproved: clamav (bionic-proposed/main) [0.103.2+dfsg-0ubuntu<IP_ADDRESS> => 0.103.2+dfsg-0ubuntu<IP_ADDRESS>] (ubuntu-server)
[00:51] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (focal-proposed) [2.664.36]
[08:28] <LocutusOfBorg> athos, hello, your python-debian upload adding zstd support broke build of debmutate
[09:27] <LocutusOfBorg> vorlon, can we remove from jammy pdns/armhf? the configure script fails because 32 bit is not supported anymore (due to 2k38)
[09:27] <LocutusOfBorg> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992593
[09:27] <LocutusOfBorg> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998816
[09:29] <LocutusOfBorg> you know, 2038 is too soon to not take care of it now :D
[09:44] -queuebot:#ubuntu-release- New binary: systemd [s390x] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:45] -queuebot:#ubuntu-release- New binary: systemd [amd64] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:49] -queuebot:#ubuntu-release- New binary: systemd [i386] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:50] -queuebot:#ubuntu-release- New binary: systemd [armhf] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[09:50] -queuebot:#ubuntu-release- New binary: systemd [ppc64el] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[10:08] -queuebot:#ubuntu-release- New binary: systemd [arm64] (jammy-proposed/main) [249.5-2ubuntu1] (core, i386-whitelist)
[11:57] <foka_> Hi! On https://launchpad.net/ubuntu/+source/golang-github-google-wire/0.5.0-1 , it shows that the armhf build failed, but when I clicked into it at https://launchpad.net/ubuntu/+source/golang-github-google-wire/0.5.0-1/+build/22577414 , it simply says "Failed to build" without any actual link to the build log.
[11:59] <foka_> Should I be concerned? I.e., will the autobuilder try to build it again automatically?  Or does it require a manual trigger to rebuild?  Many thanks!
[12:00] <athos> LocutusOfBorg: ack, I will re-work the patch with upstream this week so we can drop that delta asap :)
[12:01] <LocutusOfBorg> thanks without that fix we can't progress with transitions :(
[12:09] <cjwatson> foka_: it'll need to be retried manually
[12:10] <foka_> cjwatson: Many thanks!  BTW, how come the build log is inaccessible in this particular case?
[12:11] <cjwatson> foka_: It seems to have crashed very early before really getting to the point of creating a build log.  Not quite sure why, maybe network issue
[12:11] <cjwatson> foka_: I've retried it now
[12:11] <foka_> cjwatson: Awesome! Thanks a million!
[12:17] <athos> LocutusOfBorg: The issues lies in debmutate itself: it does not consider the possibility if a non-integer character being present in the debian revision of python-debian
[12:17] <athos> LocutusOfBorg: this was fixed in https://salsa.debian.org/jelmer/debmutate/-/commit/f4e9bd09f05dbd3291804e2c524e5e7dfc1dadbe
[12:17] <LocutusOfBorg> thanks so I start by uploading debmutate then :D
[12:18] <athos> LocutusOfBorg: It seems that the maintainer alerady cut a new release containing that fix, but he did not upload it yet :(
[12:20] <athos> LocutusOfBorg: would you like me to prepare that patch with the fix and ping the Debian maintainer for the upload? :)
[12:21] <LocutusOfBorg> athos, I'm uploading that fix in Ubuntu
[12:21] <LocutusOfBorg> I'll sync once the maintainer uploads
[12:21] <LocutusOfBorg> if you want to ping for an upload, feel free
[12:27] <LocutusOfBorg> ok as soon as you upload python-debian, debmutate should build fine
[13:15] -queuebot:#ubuntu-release- New: accepted cryptsetup [riscv64] (jammy-proposed) [2:2.4.2-1ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [arm64] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [i386] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [s390x] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [amd64] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [ppc64el] (jammy-proposed) [249.5-2ubuntu1]
[13:15] -queuebot:#ubuntu-release- New: accepted systemd [armhf] (jammy-proposed) [249.5-2ubuntu1]
[14:36] <kanashiro> ubuntu-archive: could any of you please take a look at LP #1953026 ?
[15:10] <xnox> vorlon: schopin: is openssl v3 likely to migrate soon? as it entagles with linux v5.15 migration. In the kernel team, we are discussing if we should rebuild kernel v5.15 against 1.1.1 to make it migrate; and then rebuild against openssl v3 straight after.
[15:10] <schopin> I wouldn't say soon, no :)
[15:12] <xnox> schopin:  do we need creative solution to get the remaining packages over the board?
[15:12] <xnox> schopin:  i'm sure we can afford to demote the remaining leafs to proposed.
[15:13] <sil2100> xnox: are you volunteering to help out with the openssl3 transition?! THANKS :D
[15:13] <sil2100> j/k of course ;)
[15:17] <schopin> I don't know what you mean by "demoting the leafs to proposed" ?
[15:19] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carl-meta [sync] (focal-proposed) [20.04~ubuntu1]
[15:20] <xnox> schopin:  remove package from jammy-release, publish it in jammy-proposed, and block it from migrating. For example burp serf
[15:21] <xnox> schopin:  then openssl v3 will be considered for migration, and burp serf become uninstallable mess in jammy-proposed like lots of other broken uninstallable stuff we have in jammy proposed that nobody cares about
[15:21] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carl-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[15:23] <schopin> There's still work to be done on the "rebuilding the whole world" side of things, but I'm liking this demotion move :)
[15:24] <xnox> schopin:  we always do that in the end of big transitions, cause in the end there is leftovers.
[15:35] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carleton-meta [sync] (focal-proposed) [20.04~ubuntu1]
[15:38] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carleton-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[16:13] <vorlon> xnox, schopin: openssl needs to migrate soon; please don't work around it from the kernel side.
[16:40] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carlisle-meta [sync] (focal-proposed) [20.04~ubuntu1]
[16:45] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carlisle-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[16:45] <juliank> vorlon: Should we actually set SMOOTH_UPDATES = libs oldlibs in britney.conf; such that transitions are smoothed by having new libraries in release pocket asap while keeping the old one around?
[16:46] <juliank> (I don't know the impact and how it interacts with LP)
[16:50] <vorlon> juliank: I don't know anything about the implementation of this, but it sounds on the surface like something we want
[16:51] <vorlon> in practice p-m never deletes binaries from the Ubuntu release pocket, regardless of package section
[16:52] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carl-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:52] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carlisle-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:52] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carleton-meta [amd64] (focal-proposed) [20.04~ubuntu1]
[16:55] <sil2100> vorlon, bdmurray, seb128: hey! So while looking at some intel-iot issues etc. I noticed that the daily images for focal are uh, super oversized!
[16:55] <sil2100> vorlon, bdmurray, seb128: 5.6G - for example here http://cdimage.ubuntu.com/focal/daily-live/20211202/
[16:58] <bdmurray> any ideas as to why?
[17:02] <sil2100> Didn't have time to investigate yet, sadly
[17:03] <sil2100> Weirdly, the intel-iot images weren't that oversized, ones that I built today
[17:03] <sil2100> And those basically only have a different kernel..?
[17:14] -queuebot:#ubuntu-release- New: accepted oem-sutton.newell-carol-meta [sync] (focal-proposed) [20.04~ubuntu1]
[17:18] -queuebot:#ubuntu-release- New binary: oem-sutton.newell-carol-meta [amd64] (focal-proposed/none) [20.04~ubuntu1] (canonical-oem-metapackages)
[17:23] <bdmurray> I'll try and have a look today
[17:29] <xnox> vorlon:  ok, agree. let me see if i can make any useful contributions for openssl to migrate.
[17:34] <xnox> vorlon:  are you working on fixing up https://github.com/stefanberger/swtpm/pull/620 or do you need someone else to pick up reworking changes from the feedback?
[17:45] <vorlon> xnox: not actively working on it right now but it's still on my radar
[17:45] <vorlon> xnox: I'm not officially at work right now and am only putting my oar in on openssl so that it doesn't become a bigger problem for me when I'm back next week ;)
[17:49] <bdmurray> Any idea why fenics-basix wasn't autosync'ed? bug 1953038
[17:53] <vorlon> xnox: e.g.: https://launchpad.net/ubuntu/+source/burp/2.4.0-3ubuntu1
[17:54] <vorlon> bdmurray: it did sync and was deleted https://launchpad.net/ubuntu/+source/fenics-basix/+publishinghistory
[17:54] <vorlon> sil2100: ^^ you said 'temporarily removed', should it be restored now?
[17:56] <bdmurray> vorlon: ah, thanks!
[18:01] <xnox> uploaded swtpm fixup for openssl v3
[18:09] <vorlon> juliank: why is britney selectively listing output of reverse-dep autopkgtests under https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openssl for packages whose tests have passed on all archs?  I've never known the suppression of excessive verbosity to be buggy before
[18:10] <juliank> vorlon: I'd have to investigate that
[18:12] <foka_> Hi again! https://launchpad.net/ubuntu/+source/golang-github-rogpeppe-go-internal/1.8.0-3/+build/22579307 failed to build with no build log. Does it need to be retried manually too?  :-)  (Thanks in advance!)
[18:12] <xnox> uploaded tpm2-pkcs11 fixup for openssl v3
[18:12] <xnox> foka_:  yes, retried.
[18:13] <foka_> xnox: Wow, that was quick. Many thanks!
[18:15] <xnox> foka_:  yeah s390x is fast =)
[18:15] <xnox> build completed and awaiting publishing
[18:17] <foka_> xnox: Thank you for your quick responses!  And wow, that build on s390x is fast too!
[18:17] <vorlon> hmm hmmm libcrypt-openssl-pkcs12-perl fix or toss
[18:17] <vorlon> no revdeps
[18:17] <vorlon> and I'm not enthusiastic about fixing all this perl
[18:21] <foka_> By the way, is there any automatic mechanism for notifying someone, say, the release team, or the package maintainer, about such failed builds?  Or do they get caught only when someone notices them, e.g. in proposed-migration update_excuses?
[18:28] <xnox> foka_:  +1 / release team, do notice this on update_excuses as missing builds .....
[18:28] <xnox> it is rare
[18:28] <xnox> merging m2crypto to see if it will get better
[18:36] <kanashiro> vorlon, when you have some time could you please take a look at LP #1953026 ?
[18:36] <foka_> xnox: I guess I was "lucky" that it happened to two of my packages uploads two days in a row, i.e. golang-github-google-wire/0.5.0-1 on armhf yesterday (which cjwatson fixed for me), and golang-github-rogpeppe-go-internal/1.8.0-3 on s390x today, probably due to transient network issues.
[18:37] <foka_> xnox: But yeah, normally it is rare, and I suppose these missing builds are usually dealt with before a new release. :-)
[18:39] <foka_> xnox: I happen to be trying to get hugo 0.89.4-2 migrated from proposed, and that's why I happen to be watching its dependency, golang-github-rogpeppe-go-internal-dev (>= 1.8.0)  :)
[18:47] <foka_> xnox: I think I was a bit greedy and hoping for some kind of automatic daily or weekly rebuild mechanism for such fails-before-build-environment-has-sprung-up would exist, but indeed, it is easier said than done.
[18:49] <foka_> xnox: Anyhow, thank you so much for your help!  I am so glad I can always reach out to this channel #ubuntu-release and have my problems solved so promptly!  Thank you all!
[18:51] <vorlon> LocutusOfBorg: pdns/armhf removed (relevantly, because Debian has also done the same and the package has migrated to testing)
[18:53] <vorlon> kanashiro: for future reference, the checks I want to see output from to be sure there are no revdeps are 'reverse-depends src:ruby-ferret' and 'reverse-depends src:ruby-ferret -a source'; to cover a) any binaries of different names without me having to look it up, and b) test-rev-deps in addition to build-deps
[18:55] <kanashiro> vorlon, ack, do you want me to do that now?
[18:55] <vorlon> kanashiro: nah, doing it now
[18:55] <kanashiro> vorlon, sorry for the extra work
[18:55] <vorlon> anyway I've done the first two and will deal with the ruby-psych tree after lunch
[18:55] <kanashiro> ty!
[18:57] <vorlon> kanashiro: did you have a specific recommendation wrt what do do with jruby and its reverse-dependencies?  do you expect these to require further sourceful uploads to be installable again in the future?
[19:00] <kanashiro> vorlon, I am not closely following what happens with jruby but the puppet maintainers were trying to get jruby in shape, I am not sure about the current status
[19:01] <vorlon> right - the purpose of the question is to know, when removing these packages, if I need to tag them for us to re-add on the Ubuntu side if and when Debian fixes ruby-psych without there being uploads of jruby etc
[19:02] <vorlon> if the answer is "the current package will never work again in Debian or Ubuntu with ruby3.0 without a sourceful upload", then I can just delete
[19:03] <kanashiro> it will require a sourceful upload
[19:21] <xnox> vorlon:  sil2100: nodejs, should be built against internal openssl. In the past it was done when nodejs major version declared 1.0.2.x openssl abi for its modules; and then we switched to system one once nodejs itself switched to system openssl.
[19:22] <xnox> vorlon:  sil2100: the next nodejs i.e. 17 will have to use internal openssl too, because they are not using upstream openssl but the quick openssl 3 fork.
[19:28] <xnox> merged m2crypto, and tried to fix a few things in it.
[19:28] <xnox> it does not seem like m2crypto is openssl v3 ready
[19:28] <xnox> i still get some test suite failures which i cannot explain.
[19:38] <xnox> i wonder if we can somehow ship nodejs v18 in 22.04
[20:34] <vorlon> kanashiro: ruby-psych b-d: jruby, jruby b-d: ruby-psych, are we going to have an annoying rebootstrap here?
[20:39] <xnox> uploaded nodejs, and already regret it
[20:39] <xnox> cause it will trigger the world of tests; and like spam me into the new year about failing to migrate
[20:39] <xnox> but it is the right thing to do for the openssl v3 transition.
[20:55] <vorlon> kanashiro: so actually it looks to me like plm will not need a rebuild for ruby3.0, it just needs jruby to be present; therefore I'm adding it to extra-removals
[20:57] <kanashiro> vorlon, ack
[20:58] <vorlon> kanashiro: jruby also has no runtime dependencies on ruby, aside from ruby-psych; so I'm not clear why this would need a sourceful reupload in Debian either. So I'm going to just add it to extra-removals as well to be on the safe side
[20:59] <xnox> mwhudson:  https://launchpadlibrarian.net/571939110/buildlog_ubuntu-jammy-amd64.m2crypto_0.38.0-1ubuntu1_BUILDING.txt.gz if you want to have some fun
[20:59] <xnox> somehow it doesn't like calling readlines()
[20:59] <xnox> and if one skips that test, some other test bombs out, skip that one too, it bombs more.....
[21:00] <xnox> as if something is stuck inside shared library.
[21:02] <vorlon> xnox: any objections to me dropping libcrypt-openssl-pkcs12-perl?
[21:05] <vorlon> xnox: and shall I start looking at serf?
[21:05] <vorlon> n/m that's already fixed
[21:05]  * vorlon refreshes
[21:07] <vorlon> ginggs: do you understand why python3.9 autopkgtest is failing with new openssl only on ppc64el?
[21:10] <sergiodj> I'm looking at groonga and lighttpd (both blocking libxcrypt).  I can't reproduce the failure with the former, and the latter is apparently having problems with the proxy when it accessing <IP_ADDRESS>.  some mistery for this afternoon
[21:11] <xnox> vorlon:  took a stab at improving m2crypto, but don't understand the last failure and if it is safe to ignore or not (and skipping that one bombs out in the next test case, and so on)
[21:11] <xnox> let me see libcrypt-openssl-pkcs12-perl
[21:11] <vorlon> xnox: I've already removed it you took too long to object.  You're welcome to look at it though :)
[21:12] <vorlon> leaf perl package, tries to do high-level pkcs12 stuff and the test suite is laconic
[21:12] <xnox> laconic you say
[21:12] <vorlon> :)
[21:13] <vorlon> well there's plenty of noise, but e.g. it says certificate() doesn't produce desired output but can't be bothered to show the output it does produce
[21:24] -queuebot:#ubuntu-release- Unapproved: rejected liboping [source] (bionic-proposed) [1.10.0-1ubuntu0.1]
[21:26] <xnox> vorlon:  so libcrypt-openssl-pkcs12-perl builds and passes all tests if i export openssl cnf to load legacy provider.
[21:26] <vorlon> xnox: feel free to implement that in the source then :)
[21:26] <xnox> vorlon:  i don't think that perl module itself should be doing it, but also i kind of think it is a pointless module if one needs to load legacy provider externally
[21:27] <xnox> vorlon: i saw you make it do that in blurp thing, which is ok, not sure about doing it here.
[21:27] <vorlon> ok
[21:28] <vorlon> fwiw I just retried a bunch of tests related to the other perl ssl modules since they look like they all want migrating together w/ perl-openssl-defaults
[22:08] <xnox> vorlon:  python3.9 fails on every arch with new setuptools due to module-install-local FAIL stderr: /usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
[22:08] <xnox> module-install-user  FAIL stderr: /usr/lib/python3/dist-packages/setuptools/command/install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other standards-based tools.
[22:09] <xnox> vorlon:  but it is harmless, because everything passes, i.e. testsuites, it's just allow-stderr on those module install tests
[22:09] <xnox> (or rewritting module install autopkgtest to not use deprecated commands)
[22:33] <vorlon> xnox: ack
[22:33] <vorlon> autopkgtest for python-cryptography: amd64: Test in progress, arm64: Test in progress, armhf: Test in progress, i386: Test in progress (will not be considered a regression), ppc64el: Test in progress, s390x: Test in progress
[22:33] <vorlon> what is this noise
[22:34] <vorlon> new version of the package in -proposed, hmph, lousy reason
[23:10] <vorlon> xnox: erm I just looked at the nodejs upload; how in the world is it right to switch to a vendored openssl instead of keeping openssl1.1 around as a separate source package?
[23:12] <vorlon> also what's the deal with the amd64 ftbfs, I guess it's docs?


[07:58] <lool> Morning
[10:29]  * ogra twiddles thumbs watching the squashfs building
[10:29] <ogra> gah
[10:30] <ogra> why the heck does livecd-rootfs *still* default to gutsy ...
[10:30]  * ogra sighs
[10:30] <persia> ogra: Consider it a good thing.  I could default to "unstable" like sbuild.
[10:31] <ogra> heh
[10:33] <ogra> this new commit mail format on intrepid-changes really annoys me ... why does it have to say [ubuntu/intrepid] ... what a waste
[10:33] <persia> Because Soyuz tries to be distribution independent, and may someday host more distros.
[10:34] <persia> I know there's a complete import of Debian that sometimes appears on staging, for which the mail would be different.
[10:34] <persia> As the PPA infrastructure matures, I'd not be entirely surprised to see proper remix support show up.
[10:35] <ogra> persia, i dont really care ... it could say that in the text instead of the subject
[10:35] <persia> I suppose.  File a bug :)
[10:35] <ogra> nah, to minor :)
[10:36] <ogra> Get:274 http://<IP_ADDRESS> intrepid/main linux-image-2.6.27-3-lpia 2.6.27-3.3 [21.2MB]
[10:36]  * ogra twiddles faster
[10:36] <persia> See, even minor bugs are worth filing whilst you twiddle your thumbs :p
[10:36] <ogra> heh
[10:37] <lool> ogra: Did you file the bug?  I'm also annoyed by this thing
[10:37] <lool> I could patch it out in procmail, but I prefer fixing it at the root
[10:37] <ogra> no, i didnt yet
[10:37] <lool> Especially since I don't like mangling mailing list data
[10:38] <ogra> and i think gmail can only filter on such tags in the subject ... i fear that will be the answer i'll get if filing it
[10:41] <lool> 273058
[10:41] <ogra> bug 273058
[10:41]  * ogra subscribes
[10:43] <davmor2> guys anyone using UNR here?
[10:45] <persia> davmor2: We tend not to be very helpful for such folk, and they tend to wander off.
[10:45]  * davmor2 kicks persia's shins
[10:45] <davmor2> now walk off dude ;)
[10:46] <ogra> davmor2, dont ...
[10:46] <ogra> we need ubiquity first :)
[10:46] <davmor2> No seriously now I need confirmation on a couple of bugs :(
[10:46]  * persia thanks mother for the wonderful field hockey guards
[11:07] <lool> davmor2: You want to hit ogra
[11:07] <lool> davmor2: Who's running something more or less UNR based
[11:07] <ogra> rather less
[11:07] <ogra> i only use two of their apps in my image atm
[11:07]  * lool mocks the pathetic attempt of ogra to hide from davmor2
[11:08] <lool> maximus and launcher?
[11:08] <ogra> and UNR totally doesnt use intrepid
[11:08] <ogra> yeah
[11:08] <lool> davmor2: Yeah, the big question is more intrepid/hardy
[11:08] <lool> We don't care about hardy's UNR
[11:08] <davmor2> it's okay I'll ping cgregan when he gets here
[11:08]  * davmor2 slaps lool for trying to get ogra into trouble
[11:08] <ogra> lool, there is no intrepid UNR (and there likely wont be)
[11:09] <davmor2> there's only version 1
[11:10]  * ogra wonders if it was ever made public
[11:10] <lool> ogra: I don't quite understand what you mean?
[11:11] <ogra> lool, there wont be any UNR for intrepid ... ubuntu-mobile is the closest we'll get to a netbook image
[11:11] <lool> I don't care about having an "official remix"
[11:11] <davmor2> lool: there is only version 1.0 which is based on hardy :)
[11:11] <lool> What matters is that we have intrepid UNR-alike packages
[11:11] <ogra> but my mobile is focused on touchscreens atm
[11:11] <ogra> and doesnt have any of the massive amount of app patches UNR has
[11:12] <ogra> UNR is more than the four netbook apps :)
[11:13] <persia> An "official remix" is an inherent oxymoron
[11:13] <lool> Hence the quotes
[11:14] <lool> To sum up, we could help diagnosing bugs in intrepid packages which are UNR-ish (maximus and netbook-launcher), not with hardy-based bugs
[11:15] <ogra> right
[11:15] <ogra> go-home-applet and window-picker-applet fall into that category as well
[11:20] <ogra> GRRRR !
[11:21] <ogra> umount: /var/build/chroot-livecd/proc: device is busy.
[11:21] <persia> Did you start dbus?
[11:22] <ogra> i did run: sudo livecd-rootfs-0.67/livecd.sh -d intrepid -m http://<IP_ADDRESS>:9999/ubuntu-ports ubuntu-mobile
[11:22] <ogra> nothing else
[11:22] <ogra> after adding two small blocks for ubuntu-mobile to it
[11:22] <persia> Ugly.  It oughtn't do that.
[11:23] <ogra> yeah
[11:23] <ogra> something keeps open a file descriptor in proc
[11:27] <ogra> ogra@osiris:/var/build$ lsof /var/build/chroot-livecd/proc|grep fd
[11:27] <ogra> lsof    20813 ogra    6r   DIR    0,3    0 1000864 /proc/20813/fd
[11:27] <ogra> ogra@osiris:/var/build$ ps ax|grep 20802|grep -v grep
[11:27] <ogra> ogra@osiris:/var/build$
[11:27] <lool> livecd-rootfs ought to protect from starting up daemons like debootstrap does
[11:27]  * ogra scratches head
[11:27] <lool> I see it diverts invoke-rc.d for this
[11:28] <ogra> oh, the fd is the one lspf creates
[11:28] <ogra> *lsof
[11:28] <ogra> weird
[11:28] <ogra> but still
[11:28] <ogra> ogra@osiris:/var/build$ sudo umount /var/build/chroot-livecd/proc
[11:28] <ogra> umount: /var/build/chroot-livecd/proc: device is busy.
[11:29] <lool> ogra: Any open shell?
[11:29] <ogra> no, but ...
[11:29] <ogra> ogra@osiris:/var/build$ sudo chroot chroot-livecd/
[11:29] <ogra> root@osiris:/# mount
[11:29] <ogra> sysfs on /sys type sysfs (rw)
[11:29] <ogra> binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
[11:29] <ogra> thats intresting
[11:30] <lool> Ah
[11:30] <ogra> root@osiris:/# umount /proc/sys/fs/binfmt_misc
[11:30] <ogra> root@osiris:/# exit
[11:30] <ogra> ogra@osiris:/var/build$ sudo umount /var/build/chroot-livecd/proc
[11:30] <ogra> ogra@osiris:/var/build$
[11:30] <lool> We should make livecd-rootfs unmount that
[11:31] <ogra> yeah, apparently...
[11:31]  * ogra checks what mounts it
[11:31] <lool> probably java
[11:31] <persia> But it doesn't mount it for other flavours.  I've never had that error before
[11:31] <lool> or mono
[11:31] <ogra> /etc/init.d/binfmt-support
[11:31] <persia> java isn't in -mobile.  -mid is the *only* flavour that uses Java
[11:31] <persia> Oh.  Mono.  Yeah.
[11:31] <lool> f-spot
[11:31] <ogra> well, i ran an lpia build
[11:32] <lool> It should hit Ubuntu live cds though
[11:32] <ogra> does that have mono at all ?
[11:32] <persia> Still have Mono there: I changed the seeds.
[11:32] <ogra> ah, k
[11:32] <ogra> well, i want to keep mono
[11:32] <lool> ogra: I don't have binfmt here, what's pulling it?
[11:32] <ogra> but f-spot is in the livecd since several releases
[11:32] <lool> wine?
[11:32] <lool> argh mono-common
[11:33] <ogra> hmm
[11:33] <ogra> but since when ...
[11:33] <lool> mono-common Recommends it
[11:33] <lool> Since we have recommends I'd guess
[11:33] <ogra> it didnt break on the livecd before
[11:33] <lool> Let's check with cjwatson
[11:33] <ogra> nah
[11:33] <ogra> we have livecd builds
[11:33] <persia> But why doesn't that hit the liveCDs?
[11:34] <lool> perhaps not livecd-rootfs version
[11:34] <lool> Not sure they enabled reocmmends in livecds yet
[11:34] <ogra> i pulled it from the archive
[11:34] <persia> liveCD contains recommends.
[11:34] <lool> I saw a list of recommends we should fix before enabling them
[11:34] <ogra> latest version of the package
[11:34] <lool> ogra: You'd be the one knowing whether it's in use on cdimage
[11:34] <lool> or StevenK
[11:34] <ogra> i know there is a special thing with germinate to not process recommends
[11:34] <lool> But I don't have access
[11:35]  * ogra goes to check
[11:36] <ogra> ah, meh
[11:36] <ogra> the live squashfs is built elsewhere
[11:37] <lool> On the buildds I ugess
[11:37] <lool> infinity would know
[11:37] <lool> or cjwatson
[11:37] <lool> ogra: let's ping cjwatson on this on -dev
[11:37] <lool> ogra: Going for lunch here now
[11:38] <lool> ogra: You can bring it up, or I'll check back after lunch
[11:38] <ogra> i'll do
[11:39] <crevette> hello
[11:45] <crevette> persia, did you had time to test bluez-gnome ?
[11:46] <crevette> hello by the way
[11:46] <persia> crevette: Indeed I did.  Seems to work well for comms.  I can't get my bluetooth keyboard to work, but I can't get it to work in Hardy, so I think it's me.  I'm still trying to sort it out.
[11:47] <crevette> have you the whole bluez plugin stack ?
[11:49] <persia> In hardy?  I think so.  Wasn't it monolithic?
[11:49] <crevette> humm not sure
[11:52] <persia> Yeah.  As soon as I can get it working in hardy, I'll try again with Intrepid to make sure there's no regression.  At that point, I'll be very much behind pushing the new version.
[12:03] <ogra> GRRRRRRR !!!!!!!
[12:03] <ogra> I: Retrieving Packages
[12:03] <ogra> I: Validating Packages
[12:03] <ogra> W: http://<IP_ADDRESS>:9999/ubuntu-ports/dists/intrepid/main/binary-lpia/Packages.bz2 was corrupt
[12:03] <ogra> its definately coming corrupted from the archive
[12:03]  * ogra sigs
[12:03] <ogra> *sighs as well
[12:20] <ogra> The following packages have unmet dependencies:
[12:20] <ogra>   ubuntu-mobile: Depends: nautilus but it is not going to be installed
[12:20] <ogra>                  Depends: nautilus-cd-burner but it is not going to be installed
[12:20] <ogra>                  Recommends: nautilus-share but it is not going to be installed
[12:20] <ogra> E: Broken packages
[12:20]  * ogra cries
[12:21] <ogra> and i had a proper chroot before ... damned
[12:31] <davmor2> Muhahahahahaha the evilness of the demon chroot :)
[12:31] <ogra> nah, the evil seb128
[12:31] <ogra> uploading new versions of stuff ... how can he dare
[13:49]  * ogra dd's the first ubuntu-mobile image to an USB key ....
[13:57] <ogra> meh
[13:57] <ogra> why do we have prompt in syslinux.cfg
[13:59] <ogra> grrr
[13:59]  * ogra is sitting at the boot: prompt ... no kbd on the Q1 at that point
[14:00]  * ogra goes to dig up a USB keyboard
[14:02] <ogra> hum
[14:02]  * ogra sits at an initramfs prompt
[14:16] <persia> ogra: You could just set up syslinux.cfg to timeout after 5 seconds or so...
[14:17] <ogra> well, i would like to have casper finding the squashfs first :P
[14:17] <persia> It doesn't?  Oh my.  How is your VFAT laid out?
[14:18] <ogra>  /dev/sdb is a squashfs and has casper/filesystem.squashfs
[14:18] <ogra> err
[14:18] <ogra> *is a vfat
[14:18] <persia> Right.
[14:18] <ogra> i dont see any difference to -mid
[14:18] <ogra> i even kept the preseed and boot.msg files
[14:18] <persia> Maybe the difference is in the initrd ?
[14:18] <ogra> i can mount sdb manually
[14:19] <ogra> so casper should be able too
[14:19] <ogra> for now i only want the livefs to boot, i dont even want to install
[14:20]  * ogra checks the casper script ...
[14:20] <persia> Forget install.  That's not the important part.  It's that booting a live environment also has an initrd
[14:20] <ogra> indeed it has
[14:20] <ogra> i'm in it atm
[14:22] <ogra> i can mount everything manually
[14:23] <ogra> and see the filesystem.squashfs file
[14:24] <ogra> oh sigh ...
[14:25] <crevette> persia, do we need to create a FFE ?
[14:25] <persia> crevette: We will need a Feature Freeze exception.  I suspect that the bug already exists, but until we've a successful test for the input use case, I don't really want to submit it to the release managers.
[14:26] <crevette> persia, okay sound fine
[14:26] <ogra> i forgot to set uuid
[14:26] <crevette> ah I've a wiimite so I can perahps test input on bluetooth
[14:26] <crevette> wiimote
[14:26] <crevette> I never tested input with wiimote
[14:26] <persia> crevette: Cool.  I still haven't gotten my keyboard to work.
[14:27] <crevette> don't know how much of work it requite to support wiimote input
[14:27] <crevette> requires
[14:27] <persia> Do you have a hardy install?  You'll want to test there first, and then with the old version in intrepid, and then with the new version in intrepid.
[14:27] <persia> I think there's a driver package somewhere.  I forget the name.
[14:27] <crevette> persia, I'm only have intrepid
[14:28] <persia> OK.  Then just test with the current version, and the update.
[14:29] <crevette> I don't know how was the bluez support before, so I'm not the best to talk about regression :)
[14:51] <ogra> yay
[14:51] <ogra> there we go
[14:55]  * ogra dances ... having a working ubuntu-mobile image
[14:56] <ogra> though the touchscreen doesnt work, wlan needs love and i dont get why netbook-launcher isnt used
[14:58] <ogra> but to be honest using compiz instead looks a lot better ... hmm
[14:59]  * ogra starts to agree with persia on that
[15:04] <persia> With what?
[15:06] <ogra> persia, not using netbook-launcher on mobile
[15:06] <ogra> and having compiz on by default instead
[15:07] <persia> That's likely to be more pleasing and familiar for the many users of Desktop on 7-9" devices who are the target group to switch to -mobile
[15:08] <ogra> well, the desktop is a bit boring ... but it would keep me from finding a way to expose the install button
[15:08]  * ogra wonders what to do with the examples link
[15:08] <ogra> do i keep that ....
[15:08] <ogra> or dont i
[15:09]  * ogra is surprised that devilspie seems to wor flawless
[15:09] <ogra> *work
[15:09] <persia> I'd drop it.  Many of those devices have limited secondary storage.
[15:13] <ogra> well, it doesnt get installed iirc
[15:13] <ogra> only used on the livefs
[15:14]  * ogra adds a quickfix for the touchscreen
[15:14] <ogra> to bad the wlan doesnt work :(
[15:16] <ogra> i somehow suspect i should build i386 only for now
[15:17] <ian_brasil> it says on the FAQ that the netbook remix 'predates the Ubuntu Mobile flavour' ...i thought the remix came much later
[15:18] <ogra> well, ubuntu-mobile only exists with intrepid as metapackage and image
[15:20] <ogra> nd for the image part thats even only true in some hours if ubuntu-mobile-default-settings has built and i have redone the handbuilt image
[15:20] <ogra> and i think i'll build it with -generic for now
[15:21] <ogra> not having wlan is somewhat uncomfortable
[15:25] <ogra> so someone tell me how epiphany got onto my mobile image
[15:26] <ogra> grrr, and evolution
[15:32] <persia> ogra: recommends.  Fiddle with your seeds more.
[15:32] <ogra> no recommends that would pull it in
[15:33] <ogra> heh
[15:33] <ogra> sorry
[15:33] <ogra> indeed
[15:33] <ogra> * (contact-lookup-applet)
[15:33] <persia> ian_brasil: The collection of software previously known as Ubuntu Mobile Edition became the Ubuntu MID flavour.  A new Ubuntu Mobile flavour is being introduced (neither is an Edition as such).  The Netbook Remix was released based on hardy prior to either the preparation of Ubuntu Mobile as a flavour, or full integration of Ubuntu MID with the rest of Ubuntu.
[15:34] <persia> ogra: Please do include e-d-s, even if you don't have evolution.  Also, I much prefer epiphany, personally.  Is it really that big?
[15:35] <ogra> e-d-s isnt in atm ... but i'll pull it, its small
[15:35] <ogra> the big part (100M) of evo is evo-common
[15:35] <persia> Right.  e-d-s provides very handy services for add-on applets that are likely interesting in the -mobile use case.
[15:39] <ogra> sweeeeeet !!
[15:39] <ogra> suspend/resume works, even in the livefs
[17:55] <ogra> URGH
[17:55] <ogra> that seed change wasnt so god
[17:55] <ogra> *good
[17:57]  * ogra curses loudly
[17:58] <persia> What did you do?
[17:58] <ian_brasil> persia: i didn't know that
[18:00] <ian_brasil> the new ubuntu mobile flavour will still be based on lpia
[18:00] <persia> ian_brasil: Which part especially?  Maybe I should write a history somewhere.  While I've only been trolling this channel for about 5 months, I seem to have seen a lot.
[18:00] <ian_brasil> the part about old ubuntu mobile became MID
[18:01] <persia> I don't think so.  None of the dirty hacks that make MID so lpia specific exist for Mobile.  Ideally, we'll be able to pull them out of MID at some point as well.
[18:01] <persia> Of course, there aren't any non-lpia MIDs on which one can run Ubuntu, so it's not so important, but there's heaps of older subnotebooks on which Mobile might be the best flavour.
[18:02] <ian_brasil> so what charcteristics will mobile have then..
[18:02] <persia> ogra: Got any screenshots?
[18:02] <ian_brasil> customized for 7" touchscreens..based on hildon/clutter?
[18:03] <persia> Designed for 7-9" screens.  Mostly based on GNOME.
[18:03] <ian_brasil> i like the focus on old subnotebooks btw
[18:04] <persia> They aren't really that different, except that they didn't have the marketing push.  With the new "netbook" craze, there's not really that much different in the shops here, and one can still find lots of used stuff that is nearly the same form factor, just older generation tech.
[18:04] <persia> Mind you, getting more than an hours battery, especially with WiFi, is hard on those, but that's a different issue :)
[18:05] <ogra> well, the current mobile seed is focused on 7-9" touchscreen devices
[18:05] <ogra> and my current build is for x86 ... not lpia
[18:05] <ogra> though i might change that
[18:06] <persia> ogra: I think you ought just do it for all arches.
[18:06] <ogra> i will
[18:07] <ogra> but not the handbuilt images i'm doing atm
[18:07] <ogra> i want something that works
[18:07] <persia> Oh, of course not :)
[18:07] <ogra> and lpia is just to broken on the Q1
[18:07] <ogra> i just tried that
[18:07] <persia> It's the kernel.
[18:07] <ogra> yeah
[18:07] <ogra> grrr
[18:07] <ian_brasil> yes..i have been looking at the power stuff recently..in my tests running skype is a nightmare. are you using the ipw2100 patch for wireless?
[18:07] <ogra> why did livecd-rootf bork now
[18:08]  * ogra needs to go shopping for dinner
[18:08] <ogra> back soon
[18:11] <persia> ian_brasil: Also, I don't want to get you too excited about older subnotebooks.  Mobile is being 90% tested on the Q1.  While it ought to work for other stuff, there's no guarantee it works perfectly for anything, really.
[18:13] <ogra> and how do you define "older" ?
[18:13] <ogra> like no GL support ?
[18:14] <persia> like not lpia.
[18:14] <ogra> ah
[18:14] <persia> My favorites are the Casio Hello Kitty notebook (1GHz Crusoe), and the Sony PCG-1 (a crusoe + 512M RAM jammed into a camcorder)
[18:15] <ogra> i wonder if wither works with the generic kernel
[18:15] <persia> (not that I have either of those devices: they're just nifty).
[18:15] <ogra> *either
[18:15] <persia> The Hello Kitty device had a nifty 256MB flash device for faster boot into linux.
[18:16] <persia> No idea.  I think we support Crusoe, but the number of Crusoe users is very small these days.
[18:16] <ogra> yeah
[18:16] <ogra> and i'm not sure they dont need -386 instead of -generic
[18:19] <persia> They supposedly had all the i686 instructions.  Plus one got to say "You only have a 640bit processor?  How last year.  This little notebook has a 256-bit processor".
[18:25] <persia> Hmm.  Looks like there were sufficient performance issues with the Edgy kernel that most Crusoe users self-compile kernels now (from forums and bug traffic).  We still ship LongRun, and the docs seem up to date, but I'm guessing it's a bit of a special case now, and not properly supported.
[18:25] <ian_brasil> so the old ubuntu mobile of which the reference device was the Q1 is now part of the netbook remix and the new ubuntu mobile flavour will still have the Q1 as a reference device (just want to make sure i understand)
[18:26] <persia> Or maybe not: I'm finding a few references to people happy with the Gutsy kernel.
[18:26] <persia> ian_brasil: No.
[18:26] <persia> ian_brasil: It's far more complicated.  I'll try to explain (at least as far as I know).
[18:26] <ogra> mid uses hildon and is aimed for 4-7"
[18:26] <persia> OK.  First, there was the announcements of the Ubuntu Mobile and Embedded Initiative.
[18:27] <ogra> mobile uses gnome and is aimed for 7-9"
[18:27] <persia> This was an extension of the GNOME Mobile and Embedded Initiative.
[18:27] <ogra> buth can be run on the Q1
[18:27] <persia> This was confusing to many people, because of the preexisting (and now mostly defunct) Ubuntu Embedded team who was working to get something like emdebian working for Ubuntu.
[18:27] <ogra> *both
[18:28] <ogra> but mobile will be better suited ... mid will be better suited for i.e. the small gigabyte device
[18:28] <ogra> mid looks quite clunky on the Q1
[18:28] <ogra> due to the screen size
[18:28] <persia> As time passed, most of the focus of the Ubuntu Mobile and Embedded Initiative was focused on getting hildon and moblin into Ubuntu, and porting to the new lpia architecture.
[18:29] <ian_brasil> persia: yes, i remember this time
[18:29] <persia> During the hardy cycle, there was work towards getting something to work on various devices, based on the "menlow" and "mccaslin" platforms from Intel.
[18:29] <persia> This work didn't complete within the hardy cycle, and continued in a PPA.
[18:29] <persia> This resulted in the first image releases of Ubuntu MID (which was then given an actual name).
[18:30] <persia> Due to other nomenclature cleanups, the Ubuntu Mobile and Embedded Team became the Ubuntu Mobile Team, as it didn't really include the Ubuntu Embedded folk.
[18:31] <persia> So, sometime after hardy, Ubuntu MID was first released from a PPA, and was the work of the team now known as the Ubuntu Mobile Team.
[18:32] <persia> While Ubuntu MID was always targeted for 4-6" devices, none of the developers had these, so most of the work was done with testing on the Samsung Q1 or somewhat awkward development kits.
[18:32] <persia> Completely independently, a set of Canonical developers from the OEM team was looking at technologies to support the new "netbook" devices.
[18:33] <persia> Using a mix of GNOME, OpenHand stuff, some of the work that went into Ubuntu MID, and additional development, they produced the "Netbook Remix", based loosely on Ubuntu Hardy.
[18:33] <persia> This Remix included 4 new packages, and patches to about 59 more.
[18:33] <ian_brasil> persia: ah, this was the bit i was missing >> Completely independently, a set of Canonical developers from the OEM team was looking at technologies to support the new "netbook" devices.
[18:34] <persia> (some people quibble about whether this is a Remix, but that's a side issue).
[18:34] <persia> The resulting Netbook Remix was released previously to the first release of Ubuntu MID.
[18:35] <persia> At the UDS for intrepid, there were demonstrations of preliminary versions of both Netbook Remix and Ubuntu MID.
[18:35] <persia> There were also demonstrations of additional stuff based on Ubuntu MID done by the Canonical OEM team.
[18:35] <persia> There was also a demonstration done of the Edubuntu CMPC image.
[18:36] <persia> As a result of various people looking at various devices running various environments, it was determined that there should be an Ubuntu Mobile flavour.
[18:37] <persia> So, for Intrepid, there is work to create Ubuntu Mobile.  This is designed for the 7-9" screens, and is likely to work best on the Samsung Q1 (as that happens to be the 7-9" hardware most likely to be owned by the developers working on this flavour).
[18:38] <persia> That said, Ubuntu Mobile doesn't have any of the hardware settings or hardcoded configuration that was present in the Hardy-based Ubuntu MID, and so should not be nearly so tied to the specific device.
[18:39] <persia> Additionally, one of the goals for Hardy for Ubuntu MID was to move away from all the hardcoding, and so enable a wider variety of devices (perhaps including some that are actually the target size, like the Aigo MID and Sharp D4).
[18:39] <persia> And that brings us up to date.  Any questions?
[18:40] <ian_brasil> that is really useful stuff...i will put it in a history wiki page mayne...what do you think?
[18:43] <persia> Sounds like a good idea.  Please note that I could be completely mistaken about some or all of it.  While I follow lots of communications, the above doesn't really represent an official history, but more of just a summary of what I've collected from the not-quite-oral tradition.
[18:44] <persia> Also, it might be worth linking http://www.markshuttleworth.com/archives/151 when mentioning the Netbook Remix, as sabdfl does a far better job than I of describing the intent and history of Netbook Remix.
[18:44] <ian_brasil> persia: well i have followed the project for a while and never knew some of that so i think it is useful anyway...
[18:45] <persia> ian_brasil: You've been following the mobile efforts longer than I: some of the beginning of what I wrote comes from perceptions from elsewhere in Ubuntu.
[18:46] <ian_brasil> right, the OEM team looking at the netbook stuff was what threw me
[18:46] <persia> Yeah, it threw everyone.
[18:48] <ian_brasil> :)
[18:48] <persia> I think the issue is confusion about Canonical and Ubuntu.  While Canonical sponsors a fair degree of Ubuntu development (45% of the top 20 Ubuntu uploaders for Intrepid are Canonical employees), and provides a number of Ubuntu related services, there are many people at Canonical who work on other things (and may use Ubuntu as a base)
[18:56] <ian_brasil> and the arm side of things...is this an official OEM project or part of Ubuntu Mobile or linked with the Nokia Ubuntu Arm stuff?
[18:59] <ian_brasil> or just something which some devs are looking at in their spare time
[18:59]  * ian_brasil knows ubuntu devs do not have spare time but anyway
[19:00] <persia> heh.  Most Ubuntu Devs work on Ubuntu only in their "spare time" :)
[19:01] <persia> I don't know of any OEM ARM projects, but I wouldn't know anyway.
[19:02] <persia> If there is an ARM port, it's not likely to be closely tied to Ubuntu Mobile, but rather more general.  Of the various people I've heard talking about Ubuntu ARM over the past couple years, the three most active areas have been Mobile, Xubuntu, and Server.
[19:04] <persia> Compare to Ubuntu powerpc: not all flavours are supported, as the developers of some flavours don't have test hardware, etc., but there's nothing specific to Desktop or Server there.  I know at least one person is interested in getting Ubuntu Studio working on powerpc, but it didn't last I heard.
[19:04] <persia> By "Nokia Ubuntu ARM stuff", do you mean mojo.handhelds.org, or something else?
[19:05] <ian_brasil> i mean mojo
[19:05] <persia> I don't know of any specific interactions.  There was someone from Debian ARM at UDS during the ARM discussion session, but I don't remember anyone from mojo.
[19:07] <persia> I suspect that if ARM becomes a launchpad supported architecture, the mojo work would largely cease (as there's no need to recompile everything if it is already compiled).  I'd hope most of the developers involved (whether Nokia or not) would contribute directly to Ubuntu.
[19:10] <ian_brasil> me too..makes sense
[19:11] <persia> I'll admit to an interest personally, but even though I have a device known to work with mojo, I've not gotten around to reformatting and installing.
[19:13] <ogra> note that some of the ubuntu mobile team attended the maemo simmut last weekend
[19:13] <ogra> though more with the focus on hildon 2.2
[19:15] <persia> hildon 2.2 is going to be a *huge* improvement for Ubuntu MID.  We don't have a sufficiently active upstream right now, and it shows.
[19:16] <ian_brasil> ogra: yes i saw that lool was going. Would be nice to hear what he found out
[19:16] <ogra> i was there as well
[19:17] <ogra> we'll try to get hildon 2.2 into jaunty and base mid on it
[19:17] <ian_brasil> ogra: sorry i did not know
[19:17] <ogra> hildon 2.2 is supposed to be a clutter/gtk mix seems to be intresting
[19:17] <ogra> i attended some talks about it
[19:18] <ogra> they are also trying to establish some policies like any item needs to be 9x9mm on screen so its finger usable
[19:18] <ian_brasil> they == gnome mobile
[19:18] <ogra> the nokia folks
[19:19] <ogra> the are hildon 2.2 upstream
[19:19] <ogra> and we'll try to pull their code in
[19:19] <ogra> s/the/they/
[19:20] <ogra> well s/nokia/maemo .. probably ... there is a lot from the community in it ... but nokia hosts it
[19:21] <ogra> and they slowly seem to get how they have to treat a community ... finally a summit after they just grabbed the code for three years
[19:21] <lool> Most of the hildon bits themselves are Nokia's
[19:22] <ogra> ah
[19:22] <ogra> i wasnt aware ... it sounded the other way round to me
[19:22] <lool> maemo was mostly writing apps these days
[19:22] <ian_brasil> i thought hildon was written by nokia and then they opened itti GMAE
[19:23] <lool> hildon was always open to my knowledge
[19:23] <lool> it was not always developed openly, but I don't think it was ever released closed source
[19:23] <lool> anyway
[19:24] <lool> They now try to involve the community in where the platform should go
[19:24] <lool> Like what bindings to provide, announcing that the 2.2 will be clutter based, etc.
[19:29] <ian_brasil> lool: yes that is excellent to see..along with the opening of lots of closed stuff like the WLAN driver and so on
[19:29] <lool> Yup
[19:29] <lool> Just telling people in advance what will be in the next hardware was incredible
[19:34]  * lool waves &
[19:38] <ian_brasil> persia: https://wiki.ubuntu.com/MobileTeam/Mobile/History
[19:46] <ogra> you should probably mention that there will be a ubuntu-mid.img as well as a ubuntu-mobile.img for intrepid ... while the latter is only a first shot release to base further work in jaunty on, the mid image will actually be an improved one from the hardy release
[19:48]  * persia edits
[20:00] <persia> ian_brasil: I'm not sure of the current status of the Embedded folk, and while I don't think they are active, I don't want to claim they aren't in a wiki page when it could be taken for a semi-official statement.  I also removed a few phrases that were clearly mine, and added some links.
[20:01] <ogra> you are so selfish ... not giving away your phrases
[20:01] <ogra> :)
[20:05] <persia> I prefer to think of it as keeping the floor clean, rather than leaving my footprints everywhere.
[20:07] <ogra> that way you'll never get famous :P
[20:53]  * ogra slowly starts getting aggressive after about 100 failed image build attempts
[20:54] <ogra> sigh any why does xscreensaver end up in the image now
[20:57] <persia> ogra: I think that was rss-glx
[20:58] <ogra> nope
[20:58] <ogra> only suggests
[21:00] <ogra> ogra@osiris:~/Devel/packages/mobile-meta-1.113$ apt-cache show xscreensaver-gl|grep Recommends
[21:00] <ogra> Recommends: xscreensaver | gnome-screensaver
[21:00] <ogra> the only Recommends that exists
[21:00] <ogra> and thats fulfilled by gnome-screensaver
[21:00] <ogra> so cant be it
[21:01] <persia> Yes, but germinate is silly.  Swap that around.
[21:01] <ogra> i surely wont
[21:01] <persia> OK.
[21:01] <ogra> and livecd-rootfs doesnt use germinate
[21:01] <ogra> only apt
[21:01] <persia> Hrm.
[21:01] <ogra> which gets provided the list of packages from the metapackage
[21:02] <ogra> RAH !
[21:02] <ogra> Fetched 4839kB in 4min22s (18.4kB/s)
[21:02] <ogra> W: Failed to fetch http://<IP_ADDRESS>:9999/ubuntu/dists/intrepid/universe/binary-i386/Packages.bz2  Hash Sum mismatch
[21:02] <ogra> 103rd try
[21:03]  * ogra starts over *again*
[21:10]  * ogra doesnt have any idea what to do anymore the script permanently locks up on "intrepid/universe python-gtkglext1 1.1.0-3.1 [144kB]"
[21:10] <ogra> at least for the last 20 tries


[16:54] <hyperair> what icons does indicator-power use when the battery is charging?
[16:55] <hyperair> i can't seem to figure out why it's bypassing my theme and digging out a horrible fallback icon.
[17:02] <jbicha> hyperair: https://bazaar.launchpad.net/~indicator-applet-developers/indicator-power/trunk.13.10/view/head:/src/device.c
[17:03] <hyperair> jbicha: that's what i was digging through, and still haven't found the correct icon
[17:03]  * hyperair sighs
[17:06] <jbicha> cd /usr/share/icons; find -name battery-*charging-symbolic*
[17:07] <hyperair> this is odd.
[17:07] <hyperair> i'm using Humanity-Colors-Dark-Red
[17:07] <jbicha> line 398, there's several fallbacks
[17:08] <hyperair> i know
[17:08] <hyperair> if i ste my icon theme to ubuntu-mono-dark, the correct battery icons appear
[17:08] <hyperair> but if i set it to Humanity-Colors-Dark-Red, the fully-charged icon is wrong.
[17:08] <hyperair> but index.theme has ubuntu-mono-dark as a dependency
[17:09] <jbicha> Unity isn't really designed for theming; theme developers have to duplicate what ubuntu-mono* does :(
[17:10] <hyperair> so icon dependencies don't work, you mean?
[17:10] <hyperair> that's ridiculous.
[17:11] <jbicha> some day, bug 903819 will be fixed and ubuntu-mono-dark and -light can be replaced by a single Ubuntu symbolic theme
[17:11] <hyperair> so much for focusing on customizability.
[17:11] <ubot2`> Launchpad bug 903819 in ubuntu-themes (Ubuntu) "use symbolic icons" [Wishlist,Confirmed] https://launchpad.net/bugs/903819
[17:12] <jbicha> I think you just have to use the same naming conventions Unity does as I'm not sure all of the indicators do fallback icons right
[17:12] <hyperair> hm okay
[17:14] <jbicha> like many indicators use *-panel as a naming convention but if they used *-symbolic it would look a lot nicer with Adwaita and other GNOME themes but I don't think Unity supports true symbolic icons yet
[17:15] <jbicha> I think indicators are slightly older than gnome-icon-theme-symbolic or at least before it became popular
[17:17] <hyperair> yeah i recall
[18:10] <hyperair> aha, i was symlinking things in the wrong size. it was supposed to be 22/, not 24/


[02:13] <QwertyChouskie> cjwatson: About how long do you think https://bugs.launchpad.net/launchpad/+bug/1779572 will take?  https://launchpad.net/~stk/+archive/ubuntu/daily hasn't gotten any updates since June 30th
[02:14] <wgrant> QwertyChouskie: We're actively investigating but there's no way to give an ETA at present.
[02:14] <QwertyChouskie> OK thanks
[08:00] <oSoMoN> cjwatson, great to see the fix for bug #1668358 merged, this is very timely as I'm going to need it for the chromium snap, is there an ETA for deployment?
[08:07] <pieq> Hello! Is there an issue with Launchpad regarding the git repos? I pushed a change 5 minutes ago, but it still doesn't appear on my Code page (the repo is still marked as updated like in the previous commit)
[08:08] <pieq> but if I git clone this repo to a different location on my laptop, it does include the changes I pushed, so it's not Git related
[08:08] <wgrant> pieq: There was an issue with one of the job runners. Should be trickling through now
[08:08] <pieq> wgrant, thanks!
[08:24] <cjwatson> oSoMoN: no immediate ETA, guessing maybe next week by the time I get around to QAing it properly?
[08:25] <knome> could somebody help us with https://answers.launchpad.net/launchpad/+question/672116 ?
[08:26] <oSoMoN> cjwatson, ack, thanks, so I'll see if I can work around the problem until then
[08:28] <oSoMoN> (for context chromium itself doesn't use svn, but it requires a very recent build of clang which it checks out from svn at build time)
[08:53] <cjwatson> knome: We reserve anything ending in "-admin" to avoid conflicts with mailing list addresses.  Can you possibly just use xubuntu-website-admins instead
[08:53] <cjwatson> ?
[08:54] <cjwatson> There are quite a few -admins teams already, so it's a reasonably well-established pattern
[09:03] <knome> cjwatson, sure, i didn't know of that conflict avoiding.
[09:04] <knome> is that a team name i can create myself?
[09:05] <cjwatson> knome: Should be
[09:05] <knome> ok, thanks!
[09:06] <knome> cjwatson, ah, there we go indeed. much appreciated!
[09:07] <cjwatson> no problem, sorry for the delay, it took me a little while to figure out why it wasn't working for you before
[09:07] <knome> no problem, this wasn't critically pressing :)
[09:07] <cjwatson> my neural evaluate-big-lists-of-regexes parser isn't perfect
[09:08] <knome> ugh, regex. i'm not sure if i should try to avoid it even more or just learn it better one day...
[21:56] <QwertyChouskie> cjwatson: Thanks for the quick work on https://bugs.launchpad.net/launchpad/+bug/1779572 !
[22:10] <tomreyn> hi. it was just reported in #ubuntu that email address validation is currently broken, and i seem to be able to confirm this. when accessing the email address verification link in the email luanchpad sends out, then logging in to ubuntu one, the next thing you get to see is an empty page, with a 404 returned by the server.
[22:10] <tomreyn> shift-reloading does not fix it, and the email address remains unverified.
[22:13] <tomreyn> Request Id W3X22n8AAQEAAHWrv0MAAABi1 , endpoint <IP_ADDRESS>:443
[22:14] <tomreyn> the url looks like this https://login.ubuntu.com/RANDOM_STRING/token/RANDOM_TOKEN/+newemail/EMAILADRESS
[23:06] <cjwatson> tomreyn: login.u.c is separate from Launchpad.  Could you report a bug on https://bugs.launchpad.net/canonical-identity-provider with as much detail as possible?
[23:07] <tomreyn> i can, users without an ubuntu SSO account could probably not.
[23:10] <tomreyn> also thanks for your feedback
[23:18] <tomreyn> this is bug 1787496
[23:20] <cjwatson> thanks
[23:21] <cjwatson> QwertyChouskie: np - hopefully it will actually fix stuff.  I'll aim to deploy this to production tomorrow morning
[23:27] <QwertyChouskie> cjwatson: Sounds good, thanks!
[23:41] <wgrant> tomreyn: I can't reproduce that. The URL in the email is of the form https://login.ubuntu.com/token/<TOKEN>/+newemail/<EMAIL>, which works
[23:46] <wgrant> Ah, I can reproduce it when going through email verification as part of a login attempt.
[23:47] <wgrant> I see what has happened.