[00:35] <slangasek> bdmurray: the mini.iso is built from debian-installer source, so probably there; though it's possible the correct fix is "stop building the mini.iso"...
[00:36] <cjwatson> The bug sounds like a gnupg problem ...
[00:36] <cjwatson> I mean the netboot mini.isos are genuinely useful and used, and there's no particular reason they shouldn't be able to load additional components
[00:37] <cjwatson> And this is probably affecting all use of d-i netboot
[00:38] <cjwatson> Compare https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753985
[00:39] <cjwatson> Though why is sha512 needed?  Our Release/Packages/Sources files don't use it
[00:41] <cjwatson> oh, Release.gpg
[00:41] <cjwatson> publish-distro.d/10-sign-releases:                      printf '%s\n' "-u 437D05B5 -u C0B21F32 --digest-algo SHA512"
[00:41] <cjwatson> so the attached patch in comment #8 is correct and should be applied
[00:42] <cjwatson> slangasek: ^-
[00:42] <cjwatson> probably doesn't affect CDs because we re-sign Release for those, IIRC
[00:42] <slangasek> cjwatson: oh, alrighty then
[00:42] <cjwatson> (due to reconstructing Packages)
[00:43] <slangasek> bdmurray: so turns out gnupg is the right place to fix it :-)
[00:43] <cjwatson> d-i will need to be rebuilt afterwards, but that happens reasonably often anyway because hi kernel
[00:45] <bdmurray> slangasek, cjwatson: alright, thanks
[01:25] <micah> so these pages about how to get software into the software center used to exist, but now they dont and the only thing on developer.ubuntu.com are things related to mobile, where is the non-mobile stuff gone? http://developer.ubuntu.com/publish/apps/other-forms-of-submitting-apps/my-apps-packages/ http://developer.ubuntu.com/2012/02/how-to-prepare-a-compiled-application-for-ubuntu-software-center/ ?
[01:26] <micah> hm, maybe this isn't the right place for app development questions
[01:30] <micah> it looks like it was moved, and there were no redirects made for it
[05:09] <anishparanjpe> I want to find all the modules that ubuntu installed apart from those in the kernel source. Is there a list of those modules?
[06:55] <pitti> Good morning
[07:13] <pitti> stgraber: I filed bug 1410666 for tracking this
[07:49] <dholbach> good morning
[07:50] <seb128> hey dholbach
[07:53] <dholbach> hey seb128
[08:44] <LocutusOfBorg1> hi developerz!
[09:49] <flexiondotorg> Trevinho, I've had some success with adding MATE support to lp:compiz 😃
[09:49] <flexiondotorg> Trevinho, I need to tweak the plugin configuration so it is sane for MATE, but it is working.
[09:50] <flexiondotorg> Trevinho, When I am done should I submit the merge proposal against lp:compiz or is there another repo I should use?
[10:08] <flexiondotorg> cjwatson, In order to make iso images of Ubuntu MATE using my own scripts I had to create meta packages from my seeds.
[10:08] <flexiondotorg> cjwatson, I assume that I do not need to make my meta packages available for official builds because tasksel tasks are made from the seeds, correct?
[10:21] <cjwatson> flexiondotorg: It's usual to put metapackages in the archive too
[10:22] <flexiondotorg> cjwatson, So if I have meta packages for ubuntu-mate-* those should all go in to the official archive too?
[10:26] <cjwatson> flexiondotorg: Yes, I would say so
[10:29] <cjwatson> slangasek: ^- could flexiondotorg have another contact to work with to help merge all the Ubuntu MATE stuff?  I can't promise to be desperately responsive
[11:16] <flexiondotorg> cjwatson, for package uploads dholbach has been helping me, but again I know he is somewhat busy too.
[11:16] <dholbach> flexiondotorg, do you need help with anything?
[11:16] <cjwatson> flexiondotorg: It would be helpful I think if you had somebody who's a specialist in image builds.
[11:16] <cjwatson> dholbach doesn't have access to all the right pieces ...
[11:17] <dholbach> ah ok
[11:17] <flexiondotorg> dholbach, I am going to start preparing my requests for packaing. I'll subscribe ubuntu-sponsors.
[11:17] <cjwatson> But in any event it needs to not be me, because I'm mostly doing Launchpad now.
[11:17] <flexiondotorg> cjwatson, dholbach I basically have two areas I'm takling. The build system and getting some packages into the archive.
[11:17] <flexiondotorg> I think dholbach can help with the later?
[11:17] <cjwatson> The odd bit of help is fine, but not as a default contact.
[11:18] <cjwatson> Yes, I expect so.
[11:19] <flexiondotorg> cjwatson, I have submitted merge proposal to livecd-rootfs and ubuntu-cd that adds Ubuntu MATE support. They are pending.
[11:19] <flexiondotorg> cjwatson, I'm happy to do the leg work and submit the merge proposals.
[11:19] <lesshaste> does anyone maintain the bzip2 source code? The official web page has no changes since 2010
[11:19] <flexiondotorg> cjwatson, Is there anything else I should be modifying for the build Ubuntu MATE images?
[11:20] <cjwatson> flexiondotorg: Right, which is why I'm asking for my previous manager to give you a contact to get that stuff properly reviewed and merged.
[11:20] <cjwatson> And to answer that last question.
[11:20] <flexiondotorg> cjwatson, Understood. Thanks. I'll try and progress with slangasek.
[11:30] <Trevinho> flexiondotorg: lp:compiz is fine
[11:48] <flexiondotorg> Trevinho, Thanks.
[12:35] <pitti> cjwatson, xnox: I'm looking into providing systemd units for ubiquity; do you have a clever technique how to test a locally built ubiquity deb on a live system?
[12:35] <pitti> like, interrupt the boot early, scp/dpkg -i it or so? or does it require rebuilding the image (expensive)?
[12:36] <cjwatson> pitti: break=casper-bottom
[12:37] <cjwatson> then you can fiddle in /root; don't recall whether you have networking (it should be possible but maybe not by default), if it's just text files you can just edit them in manually
[12:37] <pitti> cjwatson: ah, thanks; I figure I can call dhclient -1 eth0 or so
[12:38] <cjwatson> Yeah, well you probably don't have dhclient but ipconfig from klibc-utils should be there
[12:39] <cjwatson> Or you can use stuff from /root with judicious use of LD_LIBRARY_PATH or chroot, which you'll need to do for scp anyway
[12:40] <pitti> cjwatson: that seems to work: chroot /root, mount -t proc proc /proc, dhclient -1 eth0
[12:41] <pitti> cheers
[12:41] <cjwatson> np
[12:41] <xnox> pitti: whilst above is good, I do following -> boot to desktop, fiddle with files, switch to tty1 -> service lightdm stop, killall -9 X, service lightdm start
[12:41] <xnox> pitti: note that ubiquity jobs is start on starting lightdm.
[12:41] <pitti> xnox: ah, that sounds good too
[12:41] <xnox> pitti: in systemd world, I hope you can boot to live desktop.
[12:41] <pitti> xnox: right, I'll do the  same
[12:41] <cjwatson> I can understand wanting to not get into that when bringing up systemd jobs though
[12:41] <pitti> xnox: yes, that works fine
[12:41] <cjwatson> I mean you'll definitely want to test behaviour from clean boot too
[12:41] <pitti> xnox: just the "directly to installer" mode obviously doesn't work, that's the one I want to create
[12:42] <xnox> pitti: from there start ubiquity job and it should do things. Imho, ubiquity should be highjacking default dm, cause that's what it is.
[12:42] <xnox> pitti: in general ubiquity job should pre-empt normal one, given the conditions on the kernel command line.
[12:42] <pitti> xnox: yeah, either it registers itself as "the" dm (display-manager.service) or it does like in the upstart world and starts itself before display-manager.service
[12:43] <pitti> I factorized the startup logic into scripts/start-ubiquity-dm and share that from the .upstart and the .service
[12:43] <xnox> pitti: probably before is best, cause "on exit, normal dm should start and autologin"
[12:43] <cjwatson> ConditionKernelCommandLine should make things much nicer
[12:43] <pitti> anyway, I'll put up an MP for critisizing once I'm done
[12:43] <xnox> is the current expected behaviour
[12:43] <pitti> xnox: right
[12:44] <xnox> pitti: https://wiki.ubuntu.com/DesktopCDOptions you might find it useful. "automatic-ubiquity only-ubiquity maybe-ubiquity debug-ubiquity" should run ubiquyity
[12:44] <xnox> pitti: there are also kernel options for oem-config as well.
[12:44] <xnox> (that needs porting as well)
[12:45] <pitti> xnox: yes, I'm aware of the oem-config bits, but one at a time :)
[12:50] <shadeslayer> Could someone advise me of a way to throw away changes to a file system after it's unmounted?
[12:50] <pitti> shadeslayer: overlayfs/aufs?
[12:50] <shadeslayer> pitti: I was using that, but that keeps the the changes in the upper dir
[12:51] <shadeslayer> use case : I need to expose files on a host to a schroot, and any changes inside the schroot should be thrown away
[12:51] <shadeslayer> +after the schroot is closed
[12:51] <pitti> shadeslayer: with a tmpfs as the upper dir and lazily unmounting upper dir afterwards might work?
[12:51] <pitti> shadeslayer: sounds like you are reimplementing schroot :)
[12:52] <shadeslayer> heh
[12:52] <shadeslayer> I'm using this at the moment : /var/lib/jenkins/workspace/ /var/lib/jenkins/workspace/ overlayfs rw,lowerdir=/var/lib/jenkins/workspace/,upperdir=/tmp/jenkins 0 0
[12:52] <pitti> shadeslayer: so, I don't know exactly how schroot does that, but it's by and large that -- r/o lowerdir, tmpfs (or dir) upperdir, and unmounts everything if you close the schroot
[12:53] <cjwatson> schroot uses some unionfs (aufs, overlayfs, unionfs depending on config) with a throwaway overlay
[12:54] <cjwatson> if schroot isn't throwing away the changes then you just need to adjust its config
[12:54] <cjwatson> I would just tell the fstab in the relevant schroot profile to bind-mount the relevant directory, and then schroot's own overlay handling should take care of the rest
[12:55] <cjwatson> hm, actually that's not quite right is it
[12:56] <cjwatson> I think your problem is that /etc/schroot/setup.d/10mount comes after 05union
[12:56] <cjwatson> which is normally right, but you need to get in beforehand
[12:57] <cjwatson> so unless there's some way to do it with the standard setup.d scripts that I missed, I'd add another setup.d script before 05union that does the bind-mount you need
[12:58] <cjwatson> maybe 04mount_early with a fstab-early config file in the profile
[12:59] <cjwatson> but read through the existing setup.d scripts first to see what you can do already
[13:01] <pitti> meh, scp doesn't work in casper -- netcat FTW
[13:27] <shadeslayer> cjwatson: hm, I'll have a look
[13:40] <willpearson> Hi, we are having a problem with USN-2469-1 on Ubuntu 12.04 LTS causing a problem with graphite.
[13:41] <willpearson> The change to serving the static content isn't working for us.
[14:52] <stgraber> pitti: cool, thanks, I'll upload the fix today
[14:52] <pitti> stgraber: ah, you know what's wrong?
[14:53] <pitti> seems the systemd unit also needs some love (see first comment on the bug)
[14:54] <stgraber> pitti: yeah, needs to be changed to "starting lxc or cgmanager-ready"
[14:54] <pitti> stgraber: oh, lxc depends on cgmanager? i. e. dependency loop?
[14:55] <stgraber> well, started cgmanager is bad to begin with because in a container you'll get cgproxy, not cgmanager, so you need the cgmanager-ready event. Now when you have a "starting" and depend on something else, the "starting" in this case lxc will be held until the other event is emitted (in this case started cgmanager)
[14:56] <stgraber> as upstart doesn't keep and replay the event history, that basically means hanging until cgmanager restarts and started cgmanager is emitted again
[14:56] <shadeslayer> stgraber: btw I wanted to setup a unpriv lxc container, tried following the steps here https://help.ubuntu.com/lts/serverguide/lxc.html#lxc-unpriv but I get a error that ~/ doesn't have the 'x' bit set
[14:56] <shadeslayer> stgraber: are there more proper instructions than that?
[14:56] <stgraber> shadeslayer: https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/
[14:56] <stgraber> that does mention the chmod +x (or setfacl)
[14:59] <shadeslayer> stgraber: lxc_container: confile.c: network_netdev: 482 network is not created for 'lxc.network.link' = 'lxcbr0' option
[14:59] <shadeslayer> lxc_container: parse.c: lxc_file_for_each_line: 57 Failed to parse config: lxc.network.link = lxcbr0
[14:59] <pitti> stgraber: ah, makes sense; I think I ran into this a few years ago, nice gotcha when thinking about states instead of events
[15:00] <stgraber> shadeslayer: what do you have in ~/.config/lxc/default.conf ?
[15:00] <shadeslayer> http://paste.ubuntu.com/9748358/
[15:00] <stgraber> shadeslayer: that first line looks a bit mangled
[15:01] <shadeslayer> aha indeed
[15:02] <shadeslayer> stgraber: lxc-start: conf.c: mk_devtmpfs: 1181 Permission denied - Unable to create /dev/.lxc for autodev
[15:03] <pitti> stgraber: mangled? it's perfect Klingon! :-)
[15:03] <shadeslayer> xD
[15:03] <stgraber> shadeslayer: hmm, what's in that container?
[15:03] <shadeslayer> stgraber: I just downloaded the sid container
[15:04] <shadeslayer> though trying to run it on a non-systemd utopic machine
[15:04] <stgraber> shadeslayer: ah, that'd be why, yeah, sadly that won't work until proper systemd support lands
[15:04] <shadeslayer> aha
[15:04] <stgraber> we have the patches though so hopefully that'll all land in vivid in the next couple of weeks
[15:04] <shadeslayer> I assumed the containers on the website worked
[15:04] <pitti> shadeslayer: install sysvinit-core into it (chroot into its rootfs)?
[15:05] <stgraber> yeah, that'd be a fair assumption and that's usually quite true, expect that I never got around to blacklisting sid and jessie after they switched to systemd
[15:05] <shadeslayer> now I get lxc-start: lsm/apparmor.c: mount_feature_enabled: 61 Permission denied - Error mounting securityfs
[15:05] <shadeslayer> after installing sysvinit-core
[15:07] <stgraber> shadeslayer: can you try a trusty container just to make sure that lxc itself is happy?
[15:07] <shadeslayer> checking
[15:10] <shadeslayer> stgraber: yeah, so it's a debian specific issue
[15:12] <stgraber> wheezy starts fine, but probably a bit too old for you :)
[15:12] <shadeslayer> yeah :P
[15:13] <stgraber> I've added jessie and sid to the blacklist for now so they should vanish from the list pretty soon
[15:13] <stgraber> and will come back once unpriv systemd support lands
[15:13] <shadeslayer> ack
[15:13] <shadeslayer> thanks :)
[15:14] <stgraber> pitti: so I'm really unsure what's going on with that systemd unit... Does systemd expect the command to background itself or to stay in the foreground?
[15:14] <stgraber> pitti: I assume the former so that's why I'm not passing the -f flag as I am with upstart, besides that, it's the exact same thing running in either case...
[15:14] <pitti> stgraber: usually it should stay in the foreground (Type=normal)
[15:15] <stgraber> ah, so that's probably the problem
[15:15] <pitti> stgraber: Type=forking is for daemons which fork; some can't be run in the foreground
[15:15] <pitti> stgraber: it's usually better to let them run in the foreground, to capture their stdout/err, and the extra fork is just unnecessary
[15:15] <stgraber> pitti: ok, if you're still on systemd with lxcfs installed, can you edit ExecStart and add a -f in there, see if that does the trick?
[15:16] <stgraber> pitti: yeah, agreed and I always do that with upstart, just wasn't sure that systemd had the same default behavior
[15:16] <pitti> stgraber: I'm not, but easy enough to bring one up, hang on
[15:19] <pitti> stgraber: still the same
[15:20] <stgraber> pitti: and no extra error messages this time?
[15:20] <pitti> still the same "Failed to start FUSE filesystem for LXC."
[15:20] <pitti> $ sudo /usr/bin/lxcfs -f -s -o allow_other /var/lib/lxcfs/
[15:20] <pitti> Failed opening dbus connection: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /sys/fs/cgroup/cgmanager/sock: No such file or directory
[15:20] <pitti> WARNING: failed to escape to root cgroup
[15:21] <stgraber> no cgmanager running?
[15:21] <pitti> stgraber: bug 1400394
[15:21] <pitti> stgraber: yep, systemctl start cgmanager, then start lxcfs -> runs
[15:22] <stgraber> pitti: ok, so After=cgmanager.service should become Requires=cgmanager.service then?
[15:22] <pitti> stgraber: drop the local-fs.target, not needed
[15:22] <stgraber> pitti: ok
[15:22] <pitti> stgraber: and then Requires=cgmanager.target\nAfter=cgmanager.target
[15:23] <stgraber> ah, why .target and not .service? (sorry, still new to this)
[15:23] <pitti> stgraber: Type=simple is also the default
[15:23] <pitti> stgraber: err sorry, .service of course
[15:23] <pitti> stgraber: the local-fs.target was still in my head apparently
[15:23] <stgraber> :)
[15:23] <pitti> stgraber: OOI, why KillMode=? isn't the default (control-group) ok?
[15:25] <pitti> stgraber: I tested this, and confirmed it to work (also after reboot): http://paste.ubuntu.com/9748762/
[15:25] <pitti> stgraber: before/after is ordering, requires/wants is dependencies, they are both independent (sometimes you only need one or the other)
[15:26] <stgraber> pitti: so the expected problem with cgroup killing is that lxcfs escapes its cgroup :)
[15:26] <pitti> stgraber: oha :)
[15:27] <pitti> stgraber: systemctl stop lxcfs works (no lxcfs process any more), but indeed it did escape its cgroup
[15:27] <stgraber> does systemd have some kind of fallback then?
[15:28] <pitti> stgraber: apparently so; I'm not yet familiar with that level of detail
[15:28] <stgraber> anyway, I think it's better to stick with =process for now :)
[15:28] <pitti> I learned more than I ever wanted to know about how it sets up cgroups (when I wrote the lxc user support patch), but haven't yet looked at the teardown
[15:28] <pitti> stgraber: yep, sounds fine
[15:29] <pitti> stgraber: so my diff is: add -f, drop the default Type= and the unnecessary local-fs.target, add Requires=cgmanager.service
[15:30] <stgraber> pitti: sounds like what I've got here
[15:30] <stgraber> pitti: https://github.com/lxc/lxcfs-pkg-ubuntu/commit/67f3a4d7ecc183cb1e798cc0ffc48bdae010d39b
[15:32] <pitti> stgraber: LGTM, thanks!@
[15:32]  * pitti eyes at the @, where did that come from
[15:32] <stgraber> ok, uploaded. Hopefully adt will be happy this time.
[15:34] <stgraber> pitti: so the latest cgmanager upload is supposed to enable the unit by default, is that not the case in practice?
[15:35] <pitti> stgraber: it actually is; maybe I still had 0.34, lemme check
[15:36] <pitti> no, it's 0.35
[15:36] <pitti>    Loaded: loaded (/lib/systemd/system/cgmanager.service; disabled; vendor preset: enabled)
[15:37] <pitti> stgraber: oh, I know!
[15:37] <pitti> stgraber: 0.35 doesn't enable itself during upgrades (hallyn knew about that)
[15:37] <pitti> stgraber: I figure we need to wait for a cloud image with 0.35 proper; I figure my image just got dist-upgraded from 0.34 to 0.35
[15:37] <pitti> well, it helped us spot that bug
[15:40] <stgraber> pitti: ah, I guess that makes sense
[15:57] <mitya57> ScottK, hi, what's your opinion on https://bugs.launchpad.net/ubuntu/+source/qtenginio-opensource-src/+bug/1409433/comments/3
[16:01] <pitti> stgraber: "Jenkins Fixed - vivid-adt-lxcfs 4" -- c'est de la musique dans mes oreilles :)
[16:02] <stgraber> yay!
[16:12] <mitya57> cjwatson, hi, do you think it will be possible to drop perlqt dependency from debconf? That will allow us to demote a bunch of packages (see mterry's comment on bug 1409433).
[16:20] <cjwatson> mitya57: Probably pretty hard, the B-D is needed to generate the .ui file
[16:21] <mitya57> cjwatson, can we just use the pre-generated one?
[16:21] <cjwatson> mitya57: No idea
[16:21] <mitya57> cjwatson, well, if I write the patch (which will be Ubuntu delta), will you have any objections?
[16:21] <cjwatson> mitya57: I would expect it to be hard to load the .ui at run-time (one of mterry's suggestions), because debconf has to work when unconfigured
[16:21] <mterry> cjwatson, as I mention in the bug, the file is just 155 lines.  We could patch it in or maybe even change the code to load the .ui file instead of using a .pm one
[16:22] <mterry> cjwatson, ok
[16:22] <cjwatson> I don't hugely object if you patch in the pregenerated file as long as you maintain that patch henceforth
[16:22] <mterry> cjwatson, but still.   Patching 155 lines to avoid many large packages in main seems worth it.  Do you know roughly how often that .ui file changes?
[16:22] <cjwatson> No idea
[16:22] <cjwatson> Check git history
[16:23] <cjwatson> Build-time changes are safe enough as long as you're actually going to maintain them.  Run-time changes are risky
[16:24] <mitya57> cjwatson, last change in 2010 (by you)
[16:24] <mitya57> http://anonscm.debian.org/cgit/debconf/debconf.git/log/Debconf/FrontEnd/Kde/WizardUi.ui
[16:25] <mterry> And before that, 2009, then 2003
[16:25] <mterry> mitya57, Seems like a reasonable amount to maintain.  If it changes in future and you're busy, just send me a poke.  I'll gladly take the risk to demote all those packages
[16:26] <mterry> mitya57, the 2009 and 2010 changes were just removing and adding the frontend back.  The file itself hasn't changed since 2003 it seems
[16:26] <mterry> Although I guess it was ported to qt4, which probably did have changes
[16:26] <mterry> But still.  Point is, not a frenzy of updates
[16:27] <mitya57> I think it will need to be ported to Qt 5 before Stretch
[16:27] <mitya57> But that will be easy to merge
[16:28] <shadeslayer> does anyone know if there's a way to make a package upgradable but not uninstallable? ( I'm not sure if such a state exists )
[16:29] <mitya57> mterry: I will then wait for ScottK's reply (maybe he knows other reasons why qscintilla/pyqt5 need to stay in main), and after that upload a patched debconf
[16:29] <shadeslayer> I'd prefer not to mark it as essential
[16:29] <cjwatson> make the prerm fail
[16:30] <cjwatson> hope you (a) have a good reason (b) don't put it in the primary archive, though
[16:31] <shadeslayer> heh
[16:31] <shadeslayer> sounds extremely icky
[16:46] <PaulW2U> ssh -p 60000<EMAIL_ADDRESS>[17:16] <shadeslayer> chrisccoulson: firefox question for you, if I want to rename the firefox package to say .. magic .. I imagine alot of stuff would break if I  change MOZ_PKG_BASENAME / MOZ_PKG_NAME
[17:23] <shadeslayer> chrisccoulson: so, what would be the right way to go about this?
[17:23] <davmor2> cjwatson: to make a perm fail surely you just wash your hair before the magic 48hours is up ;)
[17:24] <Odd_Bloke> Surely a prerm is a haircut?
[18:03] <kkirsche> Hey guys does anyone know where I can find the Sign On API for Ubuntu One so I can implement a sign on option using Ubuntu One?
[18:20] <kkirsche> found it http://canonical-identity-provider.readthedocs.org/en/latest/resources/token.html#token-oauth
[19:24] <dobey> kkirsche: sign on to what?
[19:24] <kkirsche> dobey: I want to extend omniauth to allow Ubuntu One as a method of authentication for web apps
[19:25] <dobey> oh, ok. thought maybe you wanted to use it in a client app on ubuntu :)
[19:27] <kkirsche> :) nope, sorry. Thanks though
[21:33] <dobey> anyone smarter regarding the archive/proposed stuff than me, that can tell me what this bit of log actually means? http://pastebin.ubuntu.com/9752159/ slangasek maybe?
[23:50] <Riddell> anyone able to tell me why the transitions I'm doing for kate4/kate and konsole4/konsole aren't going into the archive? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[23:51] <Riddell> both apps have moved to qt5 but we want to keep the plugins from the qt4 version around for apps which use them


[01:33]  * directhex pings a little
[01:34] <directhex> asac, you about?
[12:40] <asac> directhex: ?
[13:16] <directhex> asac, i forgotted. something about your hard work on updating monoish things to xulrunner 1.9 i think
[13:21] <asac> directhex: yeah. what happened?
[13:21] <asac> long time since i touched something monoish ;)
[13:21] <asac> it hink it was mono gnome stuff
[13:21] <asac> i think that debian pulled this in from us and took care for upstreaming
[13:22] <directhex> asac, erm, i think it was a "mind if we kill it dead?". gecko# has only one rdep, and the new version of that rdep has been ported to webkit#
[13:22] <asac> if all apps are happy, then yeah
[13:23] <asac> directhex: is all in main yet?
[13:23] <asac> i mean the mono webkit binding?
[13:23] <asac> i think that was kind of a blocker
[13:24] <directhex> webkit# went in, yes
[13:24] <directhex> as things have been dumping gecko# for webkit#
[13:24] <directhex> basically because gecko# causes nasty per-platform code at compile time, and webkit# is easy peasy. so for an rss client (blam), webkit# is more than enough
[13:26] <asac> directhex: what is the "per-platform" code at compile time?
[13:27] <asac> how does webkit ship on windows?
[13:27] <asac> how do you find the right webkit version on windows?
[13:27] <asac> gecko has the same code everywhere: glue
[13:28] <directhex> asac, i don't remember the specifics, but gecko# caused apps to be arch:any not arch:all in the past
[13:28] <asac> oh that. yeah thats a problem of the gecko binding then and not a problem of gecko itself
[13:29] <asac> but as i said if done properly gecko would be more cross platform
[13:29] <asac> anyway, i dont care
[13:29] <asac> its understood that we have to do our homework on the embedding front for gecko
[13:29] <asac> but now that webkit its there, its not as pressing anymore
[13:30] <directhex> i'll file a FFe on blam 1.8.6 then
[13:33] <asac> directhex: so you want to remove the mono binding completely from the archive? or just demote?
[13:33] <asac> which package was that btw ;)?
[13:34] <directhex> asac, i think meebey wanted complete removal
[13:34] <directhex> asac, the package was blam, an rss app
[13:35] <asac> BUGabundo: no. what package is the mono binding for gecko  ;)
[13:35] <directhex> gecko-sharp2
[13:35] <asac> BUGabundo: sorry that was for directhex
[13:35] <asac> (obviously)
[13:35] <asac> ah
[13:35] <directhex> binary package libgecko2.0-cil
[13:38] <asac> directhex: i would think we should keep it in the archive if it still works.
[13:40] <directhex> asac, it only works because you've patched it to buggery, though. it's pretty much unmaintained upstream
[13:40] <asac> directhex: well. the patches work, right?
[13:40] <asac> or are there issues?
[13:41] <asac> directhex: my point is just (could be that i am not in mono), that if i want to do mono html rendering that works on all platforms is there another decent solution avail?
[13:41] <asac> all platforms == != linux ;)
[13:42] <directhex> asac, depends on your toolkit, i think. short answer is: i'm not sure
[13:43] <directhex> however, i strongly suspect it's going to end up being RM'd in debian, so you really will be the only maintainer
[13:55] <BUGabundo> asac: ahh wondering what I could help with! heeh
[13:56] <asac> directhex: for now the package should be low maintenance cost. if we have issues that take time, we can still remove it
[14:09] <fta> Mozilla Bug 381900
[14:26] <gnomefreak> did the bot for umd not run today yet?
[14:33] <fta> gnomefreak, broken yesterday by the new bzr-builddeb defaults, should be fixed for the next run
[14:38] <gnomefreak> fta: ah ok thanks
[14:45] <Greenery> if i installed Firefox from the Ubuntu Mozilla Daily Build Team PPA, will it replace current Firefox from official ubuntu repo?
[14:46] <fta> if it's the same package name, yes
[14:46] <fta> ff 3.1 from the PPA will replace the one from universe
[14:47] <Greenery> ah i see
[14:47] <fta> but 3.1 and 3.2 will not replace ff 3.0 from main
[14:47] <fta> it's not a problem, it's maintained by the same team
[14:47] <Greenery> ah good to hear that, so there will be two firefox, Firefox 3.0.7 and Firefox 3.1b if I installed the beta version, correct?
[14:48] <fta> yes
[14:48] <Greenery> any news about the Qt version of Firefox?
[14:48] <BUGabundo1> Greenery: and if you want to start 3.1 you just use $ firefox-3.1
[14:48] <fta> Greenery, no progress in months :(
[14:49] <Greenery> oh how about profile? Will it use new profile?
[14:49] <BUGabundo1> it will copy the existing one
[14:49] <fta> i will clone your existing profile the 1st time you run it, then it diverges
[14:49] <fta> -i+it
[14:50] <Greenery> great, I'm gonna give it a try. Thanks!
[14:55] <asac> Qt is out of scope for jaunty
[15:02] <gnomefreak> asac: bug 232308 sounds more like a foint issue to me
[15:22] <asac> gnomefreak: more like a xdriver issue i would think
[15:22] <asac> its kind of an artifact
[15:23] <asac> what is a tiP?
[15:23] <gnomefreak> fta: you asked about pywebkitgtk yesterday. here is the release version [ubuntu/jaunty] pywebkitgtk 1.0.2-1ubuntu1
[15:23] <asac> ah i see it
[15:23] <asac> its built, but its in NEW
[15:23] <gnomefreak> asac: the very left hand side of the J at the lower hook
[15:24] <gnomefreak> hell i'm lucky i remembered him asking about it
[15:27] <Makzu> Hello
[15:27] <Makzu> I have a question or two about fta's PPA on launchpad, the one with the mozilla packages
[15:28] <gnomefreak> ?
[15:29] <Makzu> I want to try out the firefox 3.1 betas, but I want to find a 64-bit build with PGO enabled
[15:30] <gnomefreak> holy crap we skipped versions. 3.1 is going to be re-versionsed to 3.5
[15:30] <fta> ?
[15:30] <gnomefreak> Makzu: we have not started building with PGO yet You can take the source from the repo and rebvuild with PGO enabled
[15:31] <Makzu> I think I'll try that
[15:31] <fta> Makzu, we don't have any PGO builds. even upstream doesn't have PGO linux
[15:32] <Makzu> That's a shame :(
[15:34] <Makzu> The only place I've been able to find a PGO build myself was for arch
[15:34] <jdstrand> asac: does iceweasel also use the embedded libpng? what about seamonkey and iceape?
[15:35] <gnomefreak> oh way too many changes to versioning  fta will versioning changes affect your bot?
[15:36] <gnomefreak> seamonkey == iceape
[15:36]  * jdstrand nods
[15:37] <fta> gnomefreak, what version changes are you talking about?
[15:37] <Makzu> fta, the firefox-3.1_3.1~b3~hg etc etc etc is a mercurial pull of the 3.[1,5] branch, right?  Does it have any special Ubuntu sauce?
[15:37] <gnomefreak> 3.1 - 3.5 in b4 also something about 3.6 for minefeild but that may just be a mozilla site marker
[15:37] <fta> 3.5 in b4 ?? wtf?
[15:38] <fta> 3.6 ?
[15:38] <fta> eh?
[15:38] <gnomefreak> As was discussed at the delivery meeting yesterday, we're proposing to
[15:38] <gnomefreak> change the version number of Shiretoko from 3.1 to 3.5
[15:38] <fta> where is that?
[15:38] <gnomefreak> hold on a minute
[15:39] <gnomefreak> email mailing list<EMAIL_ADDRESS>i'm pastebinning it
[15:39] <gnomefreak> fta: http://pastebin.mozilla.org/630989
[15:39] <gnomefreak> asac: you might want to look at that as well
[15:40] <asac> jdstrand: why do we care for iceweasel? did we sync that by accident?
[15:40] <jdstrand> asac: I care because I'd like to update the Debian secure-testing svn to note that libpng is embedded in firefox et al
[15:41] <asac> jdstrand: its in xulrunner in debian too i would think
[15:41] <asac> jdstrand: but i havent tracked that
[15:41] <jdstrand> asac: I'd like to be able to say 'embedded, but uses system libpng' or 'uses embedded libpng'
[15:41] <asac> jdstrand: maybe mike hommey decided its better to use system png and break apng instead
[15:41] <jdstrand> oh, I thought you did did the debian stuff too
[15:41] <asac> jdstrand: i dont know ... you need to run a ldd on a xulrunner libs
[15:42] <jdstrand> asac: nm then
[15:42] <asac> jdstrand: not for stuff that is maintained upstream still
[15:42] <asac> jdstrand: at least i try to give the real maintainers a chance
[15:42] <asac> jdstrand: only for the EOL branches
[15:42] <asac> jdstrand: so 6 month after ffox 3.1 comes out i will bve in charge for that again
[15:43] <asac> jdstrand: i would think that xulrunenr does the same then we do
[15:43] <Makzu> fta, do the packages in your PPA have any special ubuntu sauce in them, or are they the same as the source I can pull from upstream?
[15:43] <asac> jdstrand: should be easy to check. just builddepnds
[15:43] <fta> gnomefreak: ok, i'm not worried, xul will be untouched, only ff will need minimal changes. I will let upstream jump 1st. once I see the bot produces firefox-3.1-3.5~b, i will jump too.
[15:43] <jdstrand> asac: I'll check them all in my schroots, thanks
[15:43] <gnomefreak> fta: ok just making sure :)
[15:43] <asac> jdstrand: whats your status in debian security group?
[15:44] <asac> jdstrand: so icedove has system-png in debian
[15:44] <asac> jdstrand: iceape was removed from lenny ... so not affected
[15:44] <jdstrand> asac: I just do stuff in secure-testing (some CVE triage and tracking of embedded copies)
[15:44] <fta> Makzu, it has a bunch of patches, and it's using the system xulrunner sdk.. which makes it even tougher to do PGO.
[15:44] <asac> jdstrand: ah ok.
[15:44] <Makzu> Ah
[15:44] <asac> jdstrand: not sure if iceape sank down to testing again. it was removed for the release
[15:45] <asac> jdstrand: so icedove has system-png
[15:45] <jdstrand> asac: basically, where our work and their works overlaps, we share :)
[15:45] <asac> which should be everything ;)
[15:45] <asac> well. at least for upstream security issues ;)
[15:45] <jdstrand> do our thunderbirds use system png?
[15:45] <jdstrand> asac: ^
[15:45] <asac> jdstrand: yes
[15:45] <jdstrand> ok cool
[15:45] <jdstrand> asac: thanks :)
[15:45] <asac> everything from 1.8 branches uses system png everywhere
[15:46] <jdstrand> asac: and by 1.8 branches, you mean 1.8 and 1.8.1, right?
[15:46] <asac> jdstrand: so our seamonkey packages as well ;)
[15:46] <fta> not 3.1 onward, because of apng
[15:46] <jdstrand> 3.1 is 1.9.1
[15:46] <asac> jdstrand: all 1.8 branches ... e.g. ffox 2 and 1.5, xul 1.8.0, 1.8.1, seamonkey 1.0 1.1
[15:47] <asac> fta: 3.0 onward
[15:47] <jdstrand> gotcha
[15:47] <fta> so i should probably update 1.9.1/3.1 in jaunty/universe too
[15:48] <asac> fta: didnt i give you an exception yesterday for just that ;)
[15:48] <asac> ?
[15:48] <asac> e.g. push b3 build1 (now build2)
[15:48] <fta> you did, but i remember reed asked us to wait
[15:48] <asac> so yeah. just push ;)
[15:48] <asac> fta: reed doesnt understand
[15:48] <fta> ok, will do later today
[15:49] <asac> fta: we can push every tag to jaunty
[15:49] <jdstrand> asac: is it accurate to say:
[15:49] <asac> fta: and i would really have that
[15:49] <jdstrand> seamonkey (1.0) and xulrunner 1.8.0 share codebase
[15:49] <jdstrand> seamonkey (1.1) and xulrunner 1.8.1 share codebase
[15:49] <asac> fta: except for the "branded" thing where i havee a strict order from firefox never, ever to release anything that has the new version in about before they release final
[15:49] <asac> jdstrand: share codebase, but dont share binaries. yes.
[15:50]  * jdstrand nods
[15:50] <asac> jdstrand: xulrunner 1.8.0 shares codebase with ffox 1.5
[15:50] <asac> (dapper)
[15:50] <asac> 1.8.1 is ffox 2
[15:50] <asac> ;)
[15:50] <asac> hehe
[15:50] <jdstrand> asac: right
[15:50] <gnomefreak> about doesnt work on any build of firefox as i recall 3.0 3.1 3.2 i think seamonkey's does work but cant test at this time
[15:50] <jdstrand> asac: I;ve been gathering these and collecting them in ubuntu-cve-tracker. I just never pinned down seamonkey
[15:50] <asac> jdstrand: so we have patches for that ;) ... just no resources to properly do it
[15:51] <asac> jdstrand: yeah. so your intuition was right ;)
[15:51] <jdstrand> :)
[15:51] <Makzu> Is there an idiot-friendly guide somewhere for building firefox from mercurial and installing it without clobbering the files that apt put in?
[15:51] <asac> so now xulrunner 1.9.1 was firefox 3.1 ... but as it seems they will keep 1.9.1 for xulrunner but use 3.5 for firefox ;)
[15:52] <jdstrand> versions == continuous fun :)
[15:52] <asac> Makzu: just clone the right mercurial tree
[15:52] <Makzu> I'd like to try putting a .deb together so that my fellow ex-ricers can also try out something possibly faster
[15:52] <jcastro> asac: python-webkitgtk is all set in jaunty now, so I guess we just rebuild gwibber?
[15:53] <asac> Makzu: then put a .mozconfig in the dir with the lines:
[15:53] <asac> ac_add_options --prefix=/home/asac/local_moz
[15:53] <asac> ac_add_options --enable-application=xulrunner
[15:53] <asac> ac_add_options --with-system-jpeg=/usr
[15:53] <asac> ac_add_options --with-system-zlib=/usr
[15:53] <asac> jcastro: webkitgtk is stuck in NEW ;)
[15:53] <asac> jcastro: in binary new
[15:54] <asac> jcastro: so ask seb ;)
[15:55] <asac> Makzu: adjust the --prefix for your own home
[15:55] <asac> Makzu: and use browser instead of xulrunner there ;)
[15:55] <asac> Makzu: then just run make -f client.mk build install
[15:56] <asac> Makzu: not sure why you want to put a .deb together
[15:56] <asac> Makzu: our packages are quite perfect and highly sophisticated
[15:56] <asac> Makzu: if you want dailies, we have them in a ppa :)
[15:57] <jcastro> asac: ah ok
[15:58] <Makzu> asac, I wanted to play around with a pgo build, is all
[15:58] <asac> jcastro: so we need to hold our breath for another day or so
[15:59] <jcastro> k
[15:59] <asac> Makzu: oh right. yeah. ok
[15:59] <Makzu> And to post the debs on the ubuntu forums for other people
[15:59] <asac> Makzu: plesae dont do that
[15:59] <asac> play around with it and provide feedback here.
[15:59] <jcastro> asac: this is less than ideal, people are waiting to test it so they can report bugs, but we'll deal with it. :-/
[15:59] <gnomefreak> ok first smoke of the day be back
[16:00] <Makzu> I can do that too :)
[16:00] <asac> jcastro: i know. it was huats fault. he should have done two steps. i already talked to him. but be nice with him, he is new and has to learn.
[16:00] <asac> jcastro: ;)
[16:00] <asac> jcastro: and he learned the lesson now. so all is good
[16:00] <asac> Makzu: thanks. floating debs are really bad
[16:01] <jcastro> asac: yeah no worries, I know he was sick for a day too, I am not complaining when a MOTU does work. :D
[16:01] <asac> jcastro: hehe. he works. it was just an unfortunate glitch in the gwibber saga ;)
[16:02] <jcastro> it's worth it, jimmac's new theme is pretty hot
[16:05] <asac> jcastro: have you tried your modem with the latest jaunty NM yet?
[16:05] <Makzu> Would the sunspider benchmark be a good objective comparison tool for PGO vs non-PGO builds?
[16:05] <asac> Makzu: sunspider is more about javascript?
[16:05] <jcastro> asac: I never owned one, a friend did and he moved out of town, however, with a jailbroken iphone and pdanet for tethering it works great.
[16:05] <asac> jcastro: ah. ok now i remember
[16:06] <jcastro> I have some guys in the LoCo with them though, I will put out the word, what's the URL for the modem feedback again?
[16:06] <asac> jcastro: yes. we have a new modem prober which allows us to catch modems we havent put into hal-info
[16:06] <asac> jcastro: so the question is acutally: is your modem still detected
[16:07] <asac> and does it still work ;)
[16:07] <jcastro> ok, I will ask him to try with a live CD
[16:07] <asac> jcastro: also if there are suddelny more than one modem entries in applet i want to know ;)
[16:07] <asac> jcastro: thanks
[16:07] <asac> jcastro: but its in since a few days. so it needs to be a daily i guess
[16:08] <jcastro> ok
[16:09] <Makzu> asac: My idea was to run sunspider or a similar js benchmark while building the profile and compare before and after numbers.. I don't know if that would be overkill though
[16:14] <asac> Makzu: for experimenting that might be ok
[16:14] <asac> Makzu: but for real packages that doesnt make sense
[16:14] <asac> Makzu: as you will just be optimizing sunspider
[16:15] <asac> also the win you get that way will probably be far more than you get when running sunspider in a normal pgo build which uses a broad set of usecases
[16:15] <asac> to generate the pgo profile
[16:15] <asac> Makzu: imo just try a normal pgo build
[16:16] <asac> Makzu: firefox already has a default testcase for profiling
[16:16] <asac> that should be good
[16:16] <Makzu> Would that be the profileserver.py mentioned on the MDC article?
[16:17] <asac> yey
[16:17] <gnomefreak> anyone have that PGO bug handy?
[16:17] <Makzu> Is that generated when I build firefox, or do I have to fetch that from somewhere?
[16:18] <Makzu> #213708, I think
[16:22] <gnomefreak> fta: your the prism guy. would bug 337176 be prism more so than firefox?
[16:22] <gnomefreak> Makzu: thanks bug 213708
[16:30] <gnomefreak> bug 338591 i really hate changin browsers
[16:31] <Makzu> asac, do I need to add mk_add_options MOZ_OBJDIR with the prefix specified, or will the prefix in ac_add_options work?
[16:32] <Makzu> wait, nvm, the prefix means I can run make install without worrying
[16:51] <Makzu> Well, I'm going to let this build, then come back in with my findings
[16:51] <Makzu> Thanks for your help, asac and everyone else :)
[16:52] <gnomefreak> great i have upstream report but no LP report i had it :(
[17:17] <gnomefreak> holy shit i think email is finally done ;) only took ~3 hours (normal day to day email)
[17:18] <gnomefreak> smoke
[17:30] <gnomefreak> off for lunch
[18:05] <gnomefreak> what the hell is wrong with bzr?
[18:08] <gnomefreak> bzr builddeb is trying to grab upstream tarball when i already have it and changelog is right
[18:16] <gnomefreak> asac: can you look at this? http://pastebin.mozilla.org/631007 dpkg-buildpackage works fine
[18:32] <gnomefreak> ok i'm out im uploading sm2b1 to ppa and it is taking way too much bandwidth to do.
[19:57] <fta> d'oh! https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[20:09] <jdong> Could not find compatible GRE between version 1.9.1b3pre and 1.9.1b3pre.
[20:09] <jdong> uhhh
[20:15] <fta> ppa?
[20:15] <fta> oh, gasp, i know, i'll fix it
[20:15] <jdong> yeah, umd ppa
[20:15] <jdong> thanks :)
[20:18]  * fta blames asac
[20:18] <jdong> haha
[20:25] <fta> well, i blame mozilla
[20:26] <fta> to solve this for good, i would need a debian/control.in where i can update the xul deps automatically
[20:33] <fta> jdong, the other solution is to just wait for the corresponding firefox: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa (the red should turn green shortly)
[20:34] <jdong> neat
[20:34] <jdong> will keep my eyes peeled
[20:59] <fta> less red...