[15:00]  * vorlon waves
[15:00]  * cyphermox waves
[15:00] <tdaitx> o/
[15:00] <waveform> o/
[15:01] <sil2100> o/
[15:01] <juliank> \o
[15:02] <vorlon> #startmeeting
[15:02] <meetingology> Meeting started Thu Mar 14 15:02:22 2019 UTC.  The chair is vorlon. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:02] <meetingology> Available commands: action commands idea info link nick
[15:02] <rbalint> o/
[15:02] <vorlon> [TOPIC] Lightning round
[15:02] <vorlon> $ echo $(shuf -e vorlon bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson juliank waveform)
[15:02] <vorlon> juliank cyphermox bdmurray xnox waveform mwhudson tdaitx infinity sil2100 rbalint vorlon doko
[15:02] <juliank> one sec
[15:02] <juliank> Let's do the daily version:
[15:03] <juliank> Fri:
[15:03] <juliank>  * apt:
[15:03] <juliank>   * 1.8.0 release
[15:03] <juliank>   * cherry-picking of the new fixes from 1.8.0 to stable branches
[15:03] <juliank>   * merging translations down the branches (1.8->1.7->1.6->1.2->trusty)
[15:03] <juliank>     - probably should do 1.6->1.4 then 1.4->1.2, though.
[15:03] <juliank> Mon:
[15:03] <juliank>  * apt 1.7.4 and 1.6.30 stable release updates
[15:03] <juliank>  * python-apt 1.8.4 release, fixing a few locking bugs
[15:03] <juliank> Tue:
[15:03] <juliank>  * apt 1.2.31 and 1.0.1ubuntu2.22 stable release updates
[15:03] <juliank> Wed:
[15:03] <juliank>  * Updated socket-activated debconf client helper for PackageKit (https://github.com/hughsie/PackageKit/pull/289)
[15:03] <juliank>  * some trello card splitting
[15:03] <juliank> Thu:
[15:03] <juliank>  * Investigated ubuntu-drivers for aptdaemon usage -> only in tests
[15:03] <juliank>  * Merged minimize-manual for live-cdrootfs/bionic
[15:03] <juliank>  * Discussed private ppa support for add-apt-repository with ddstreet and cjwatson (bug 645404)
[15:03] <juliank>  * More work on ESM UX
[15:03] <juliank> (done)
[15:03] <cyphermox> grub2 uploaded for adding the http module to EFI binary + plymouth fixes
[15:04] <cyphermox> preparing grub2 SRUs for http module, debconf prompts
[15:04] <cyphermox> cleaning up / revising the packageset update script for the DMB
[15:04] <cyphermox> debugging netplan.io autopkgtests: wifi tests failing on some architectures (on purpose), etc.
[15:04] <cyphermox> prepared and uploaded netplan.io SRUs for bionic, cosmic (now in queue)
[15:04] <cyphermox> (done)
[15:04] <bdmurray> research into how to use prometheus client for the Error Tracker
[15:04] <bdmurray> discussed with IS using a script to convert json instead
[15:04] <bdmurray> worked on conversion of an ET cronjob from pycassa to python cassandra
[15:04] <bdmurray> searched for a gdb patch for bug LP: #1818918
[15:04] <bdmurray> reported ET bug re long LP bug titles (LP: #1819199)
[15:04] <bdmurray> reported apport bug re gdbsandbox and libc6 (LP: #1819230)
[15:04] <bdmurray> review and merge of azzar1's fix for LP: #1816423
[15:04] <bdmurray> worked on lintian issues with ubuntu-release-upgrader
[15:04] <bdmurray> reuploaded distro-info for C and T with proper deps
[15:04] <bdmurray> done
[15:04] <bdmurray> xnox:
[15:04] <xnox> * Fix up LP: #1805841
[15:04] <xnox> * Completed LP: #1766865 for LUKS2/partman-crypto
[15:04] <xnox> * Fixing up MAAS images for LUKS2 LP: #1818876
[15:04] <xnox> * Upstreaming s390-tools fixes for zkey LUKS2
[15:04] <xnox> * Worked on
[15:04] <xnox>   https://bugs.launchpad.net/ubuntu/+source/atlas/+bug/1814796 to get
[15:04] <xnox>   to incomplete state, the provided patches FTBFS
[15:04] <xnox> * Worked on
[15:05] <xnox>   https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1817097 to
[15:05] <xnox>   incomplete state, actually not critical, well-known, provided
[15:05] <xnox>   workaround
[15:05] <xnox> * There are no outstanding foundations actionable items requested by
[15:05] <xnox>   IBM for s390x for disco
[15:05] <xnox> = Blocked =
[15:05] <xnox> * Responded to the OpenSSL SRU questions, awaiting for openssl to be accepted
[15:05] <xnox>   https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386
[15:05] <xnox> * Parter upload in unapproved
[15:05] <xnox> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=ibm-java80
[15:05] <xnox> https://bugs.launchpad.net/ubuntu/+source/ibm-java71/+bug/1818799
[15:05] <xnox> = Bugs to review =
[15:05] <xnox> * multipath bug (out of my breadth, maybe cpa)
[15:05] <xnox> https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1815599
[15:05] <xnox> * cryptsetup decrease memory requirement from 1GB to something tolarable
[15:05] <xnox> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1820049
[15:05] <xnox> done
[15:06]  * sil2100 pokes waveform
[15:07] <waveform> * Finished pi "amazing" spec; in for review
[15:07] <waveform> * Moving RPi patches from livecd-rootfs to linux-firmware-raspi2 (needs review)
[15:07] <waveform> * SRU for RPi.GPIO to bionic / cosmic
[15:07] <waveform> * Upgraded wiringPi package to 2.50 version
[15:07] <gaughen> waveform, it's Pi day!
[15:07] <waveform> * Testing of pi-bluetooth package on Pi3B, 3B+, (need to do 3A+) under arm64 (need to verify armhf)
[15:07] <waveform> * Investigating integration of pi-bluetooth fixes into ubuntu core
[15:07] <waveform> * More reading on ARM trustzone
[15:07] <waveform> (done)
[15:07] <tdaitx> * openjdk-11 bionic security transition
[15:07] <tdaitx>   - reviewed & uploaded packages
[15:07] <tdaitx>   - bumped & rebuild arch specific packages for cosmic
[15:07] <tdaitx>   - prepared openjdk-11 upload for cosmic
[15:07] <tdaitx> * ant fix for mrjar LP: #1808383
[15:07] <tdaitx> * unable to reproduce sweethome3d menu bug (chroot & qemu) LP: #1816791
[15:07] <tdaitx> (done)
[15:07] <sil2100> - Friday: out-of-office
[15:07] <sil2100> - A very long and busy DMB meeting
[15:07] <sil2100> - SRU reviews and releases
[15:07] <sil2100> - New kernel cycle starting
[15:07] <sil2100> - Help with package copies for OpenJDK-11 bionic/cosmic
[15:07] <sil2100> - Reviewing Steve's ubuntu-cdimage clean-up branch (first step)
[15:08] <sil2100> - core18
[15:08] <sil2100>   * Started cleanup in gadget branch permissions (again)
[15:08] <sil2100>   * Released new core18
[15:08] <sil2100>   * Prepared updates for gadgets
[15:08] <sil2100> - Packaging the WALA security fix and testing the packages + coordination
[15:08] <sil2100> - Booking for the release sprint
[15:08] <sil2100> - Addressing Laney's review concerns in the ADT-regression bug notifier
[15:08] <sil2100> (done)
[15:08] <rbalint> * added detecting wsl to systemd-detect-virt https://github.com/systemd/systemd/pull/11932
[15:08] <rbalint> * fixed libcec ftbfs with 4.0.4+dfsg1-2 via Debian
[15:08] <rbalint> * uploaded wireshark 3.0.0 to experimental (in NEW now)
[15:08] <rbalint> * tested reboot speed cycles on an old laptop
[15:08] <rbalint>   - suggested using dbus for reboot since sudo reboot bypasses inhibitor locks
[15:08] <rbalint> * verified many SRU-d unattended-upgrades bugs for Xenial
[15:08] <rbalint> * partner work
[15:08] <rbalint> (done)
[15:09] <bdmurray> vorlon:
[15:09] <vorlon>  * reverting resolvconf SRU due to regressions (LP: #1819625)
[15:09] <vorlon>  * TB work
[15:09] <vorlon>  * more trusty ESM transition discussions
[15:09] <vorlon>  * plotting around secureboot policy transition and FIPS kernels
[15:09] <vorlon>  * looking at a possible regression in trusty that may be the kernel refusing to load kernel modules signed with a key it doesn't know, while loading completely unsigned kernels (LP: #1818134)
[15:09] <vorlon>  * debian-cd, cdimage MPs for the desktop team (multilayer squashfs and canary image)
[15:10] <vorlon> (done)
[15:10] <vorlon> doko:
[15:13] <bdmurray> vorlon: so no doko?
[15:13] <vorlon> guess not
[15:13] <vorlon> any questions over status?
[15:14]  * juliank has gone sightly mad
[15:15] <vorlon> xnox: on openssl, did you put your response in the SRU bug template?
[15:16] <bdmurray> vorlon: none here
[15:16] <doko> ohh, US summer time?
[15:16] <bdmurray> doko: yeah
[15:17] <doko> sorry, didn't prepare. but still doing openjdk-11 backports
[15:17] <vorlon> ok
[15:17] <vorlon> #topic Bugs
[15:17] <bdmurray> bug 1818953 was assigned to our team
[15:17] <vorlon> [LINK] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-dd-incoming-bug-tasks.html#foundations-bugs
[15:17] <xnox> there is a patch proposed by debina developer
[15:17]  * vorlon nods
[15:17] <xnox> if no traction there, will upload into ubuntu
[15:18] <bdmurray> xnox: so should you be the assignee?
[15:18] <xnox> sure
[15:18] <vorlon> there is a trello card as well for it
[15:19] <vorlon> I don't know if infinity took it, we discussed it this week
[15:19] <bdmurray> the card has his symbol
[15:19] <vorlon> xnox: ^^
[15:19] <vorlon> bdmurray: other bugs?
[15:20] <bdmurray> bug 1819427
[15:20] <xnox> i am sure both infinity and I would love to just sync it, out of debian
[15:20] <vorlon> xnox: that's fine, but whoever does it, please close out the card so I don't have to look at it again ;)
[15:20] <xnox> bdmurray, i thought some desktopy people mentioned that they are working on it.
[15:21] <seb128> that snap/daily install has been actively looked at by Ken/Will with the snap team and has been handed to the snapd team for investigation now since it looks like a bug on their side
[15:21] <xnox> bdmurray, and strictly not a regression, rather never enabled.
[15:21] <xnox> seb128, oh, ok, thanks.
[15:21] <bdmurray> seb128: should there be another task then?
[15:21] <seb128> xnox, that bug is not about the manifest, it's about the target system missing the seeded snap
[15:21] <seb128> snaps
[15:21] <vorlon> doko: what was never enabled?
[15:22] <vorlon> indeed
[15:22] <xnox> interesting
[15:22] <vorlon> and anyway it doesn't look like a ubiquity bug based on the discussion
[15:22] <seb128> bdmurray, probably, I was waiting for them to figure out the details to triage/Reassign as appropriate
[15:22] <xnox> vorlon, listing snaps in desktop.iso's manifest
[15:22] <seb128> xnox, that's bug #1819287 and didrocks is looking at it
[15:23] <bdmurray> other than ogra's comment its not clear its been handed off
[15:23] <vorlon> it's being worked through the forum currently
[15:23] <vorlon> I don't believe it's for Foundations to drive
[15:23] <vorlon> maybe assign the bug to chipaca
[15:24] <seb128> (+1 for that)
[15:25] <vorlon> it should be targeted to disco for sure, but unless snap team identifies something in livecd-rootfs, it's not-for-us
[15:25] <gaughen> vorlon, sounds like we should raise it to the snapd team
[15:25] <seb128> it's being discussed atm on #snappy, I don't believe there is action needed on those issues
[15:26] <bdmurray> Okay should we move on then?
[15:26] <vorlon> yes please
[15:26] <bdmurray> Does bug 1396160 seem worth fixing for disco?
[15:26] <bdmurray> https://errors.ubuntu.com/problem/72c621876cfe04b51b37f8f3ef08c3da0460b462 is the most recent errors bucket
[15:28] <vorlon> bdmurray: are you proposing it because it's currently the spammiest crash for us?
[15:28] <vorlon> if so then +1
[15:28] <bdmurray> Well, that and its a bad user experience getting the crash dialog for no reason. It came up because I hit it too.
[15:29] <bdmurray> Last one, bug 1816812. What is this even about? It doesn't seem very helpful.
[15:30] <vorlon> bdmurray: right, but we know how many users the spurious dialog is affecting by how many reports we get :)
[15:30] <seb128> all gnome-classic and unity users have their logout not working
[15:30] <seb128> or rather timeouting and taking ages
[15:31] <xnox> sigh
[15:31] <seb128> https://github.com/systemd/systemd/pull/11697 has the details
[15:31] <xnox> ack
[15:31] <seb128> and it's a pretty simple patch
[15:31] <seb128> please just backport it :)
[15:31] <xnox> i think the solution is to merge the bugfix release v241 into disco
[15:31] <vorlon> what could go wrong
[15:31] <xnox> cause our disco systemd is now v240,71
[15:31] <xnox> given the number of patches we have
[15:32] <vorlon> xnox: I don't think we need to micromanage the resolution :) do you agree that we need to get this bug fixed for disco?
[15:32] <xnox> yeah
[15:32] <vorlon> ok. it's targeted, and I'll create a card for it that you can mangle to taste after
[15:33] <seb128> can I ask a rls-bug question/raise a point before you guys move to another topic? or is this meeting not the right venue? (I'm happy to email or go the appropriate way)
[15:33] <vorlon> seb128: go ahead
[15:33] <seb128> my understand of the process was that rls-<nn>-incoming list should be regularly reviewed and driven to 0 by acception or -notfixing things
[15:34] <seb128> but the foundations list has items sitting in place for months
[15:34] <seb128> so I'm unsure if it means we should escalade problems by some other mean?
[15:34] <seb128> e.g bug #1817453 is concerning desktop for the incoming release
[15:34] <seb128> but doesn't seem to get reviewed
[15:34]  * xnox doesn't desktop own ubiquity?!
[15:35]  * seb128 slaps xnox
[15:35] <vorlon>  /kick xnox
[15:35] <sil2100> ;)
[15:35] <vorlon> bdmurray: have you triaged this bug in some other manner?
[15:35] <seb128> that's recent-ish
[15:35] <seb128> bug things like bug #1802337 are on the list since novembre
[15:35] <bdmurray> vorlon: no
[15:37] <vorlon> seb128: I think in general the volume is such that we don't get through the ones of medium or lower importance
[15:37] <seb128> k, good to know
[15:37] <vorlon> but of course one of these you point out is high
[15:37] <seb128> right
[15:37] <vorlon> bdmurray: should we take LP: #1817453 now?
[15:37] <cyphermox> seb128: keyboard layouts one is a regression, I'm reasonably sure
[15:38] <bdmurray> vorlon: I think so
[15:38] <seb128> vorlon, well, looking at the report you have 1 critical and 6 high on the list
[15:38] <cyphermox> heh, well, as per the bug obviously
[15:38] <bdmurray> seb128: some of those are tagged and targetted so on both lists
[15:38] <seb128> the process is to tag -notfixing or target/untag though
[15:39] <seb128> items should never stay on -incoming if you respect that
[15:39] <seb128> (we drive our list for desktop to 0 every week and it works)
[15:40] <juliank> the keyboard stuff sounds like an off-by-1 or something bug
[15:40] <vorlon> bdmurray: so do we agree to drive this to 0 in the future, for crit+high?
[15:40] <seb128> vorlon, anyway, I didn't want to derail your meeting too long, I think it would have value to have the list driven to 0, but I also note that usually it would happen for items > medium
[15:41] <bdmurray> vorlon: sure
[15:41] <vorlon> ok
[15:41] <seb128> thx!
[15:41] <vorlon> seb128: thanks for raising
[15:41] <vorlon> [TOPIC] proposed-migration
[15:41] <seb128> np, thx for listening :)
[15:41] <vorlon> [LINK] http://people.canonical.com/~ubuntu-archive/proposed-migration/disco/update_excuses_by_team.html#foundations-bugs
[15:41] <vorlon> this is looking busier again
[15:41] <vorlon> cyphermox: you have netplan.io in progress, right?
[15:41] <cyphermox> yes
[15:42] <vorlon> xnox: you took fuse-zip last week; any progress?
[15:42] <cyphermox> finally figured a way to fix at least wifis
[15:42] <xnox> vorlon, no progress, no
[15:42] <gaughen> cyphermox, vorlon can we add that to the wiki page for running the meeting - regarding driving crit+high on incoming to zero
[15:43] <gaughen> cyphermox, vorlon and can we start using that wiki page to run the meetings?
[15:43] <vorlon> if the wiki page is linked from an entry point ;)
[15:44] <juliank> um, rbalint, there are a lot of "apt_pkg.pkgsystem_unlock() failed due to not holding the lock but trying to continue" in the u-u test log
[15:44] <vorlon> xnox: are you going to work on it this week?
[15:44] <xnox> yes
[15:44] <vorlon> ok
[15:44] <vorlon> doko: you had claimed epsilon, I think?
[15:44] <cjwatson>
[15:44] <rbalint> juliank, yes, this is a workaround for the lock being lost
[15:45] <vorlon> (python-scipy is no longer blocking things except for python-numpy, hurray for regressions in release)
[15:45] <juliank> rbalint: but i thought we fixed it so we don't lose it anymore
[15:45] <gaughen> vorlon, yes, we'll make that so #1
[15:45] <doko> vorlon: yes, still on my list, didn't find the time yet
[15:45] <vorlon> ok
[15:45] <rbalint> juliank, i hoped, but then python-apt/apt still looses it
[15:45] <rbalint> juliank, it seems
[15:45] <rbalint> juliank, it think it became better
[15:46] <vorlon> e2fsprogs is blocked by initramfs-tools, which is a false-positive, just needs rerun now that mwhudson and I have fixed busybox vs isc-dhcp client (have clicked the button now)
[15:46] <vorlon> but also blocked by systemd/arm64
[15:46] <vorlon> xnox: ^^ ?
[15:46] <rbalint> juliank, is it in disco?
[15:46] <juliank> yeah
[15:46] <xnox> vorlon, lovely
[15:46] <vorlon> xnox: not lovely, racy
[15:46] <xnox> vorlon, i had analysis pinged to me about arm64 from Laney, need to upload that.
[15:46] <vorlon> I've clicked that button now too
[15:46] <vorlon> ok
[15:47] <rbalint> juliank, at least if you see that now often it became more reproducible :-)
[15:47] <vorlon> python-numpy + python-scipy, I don't know if we have a path forward on resolving that
[15:47] <juliank> rbalint: it's in the most recent autopkgtest logs where I see it
[15:47] <vorlon> we've badtest'ed python-scipy in release, so maybe we should just do the same for the proposed version
[15:48] <juliank> 657 messages like that in the latest
[15:48]  * Laney fluffles xnox
[15:49] <vorlon> fwiw Debian isn't shipping the new scipy or the new numpy yet
[15:49] <juliank> rbalint: this should not happen at all, it should be calling apt_pkg.pkgsystem_unlock_inner
[15:49] <vorlon> and lintian is the same issue as last time
[15:50] <vorlon> so I think that covers the p-m stuff that currently needs attention
[15:50] <juliank> so, somehow, u-u ends up getting an AttributeError on apt_pkg.pkgsystem_unlock_inner()
[15:50] <rbalint> juliank, it used to work
[15:50] <vorlon> and juliank and rbalint are getting ahead on u-u + python-apt before the report marks it as 'late', +1
[15:50] <vorlon> [TOPIC] AOB
[15:50] <vorlon> anything else?
[15:51] <cjwatson> (sorry for the noise, dodgy connection)
[15:52] <juliank> ah, no, it's upgrading debian testing, that's not going to help :)
[15:52] <juliank> um, stable
[15:52] <juliank> debian stable never got any of the frontend locking stuff or the locking fixes
[15:53] <rbalint> juliank, it is upgrading snapshots, i'll move to newer snapshot points
[15:54] <juliank> well, that won't help, as there are no fixes in later snapshots either :)
[15:54] <rbalint> juliank, no fix in sid?
[15:54] <juliank> Well, yes, in sid
[15:54] <juliank> but that looks like a install security updates in stable test?
[15:54] <juliank> maybe I'm wrong
[15:54] <rbalint> which log are you looking at?
[15:55] <juliank> the latest
[15:55] <vorlon> you two can have the side conversation post-meeting ;)
[15:55] <vorlon> #endmeeting
[15:55] <meetingology> Meeting ended Thu Mar 14 15:55:10 2019 UTC.
[15:55] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2019/ubuntu-meeting.2019-03-14-15.02.moin.txt
[15:55] <vorlon> thanks, all
[15:56]  * juliank -> #ubuntu-devel
[15:58] <sil2100> vorlon: thanks o/
[16:11] <xnox> vorlon, updated the regression potential section of the openssl sru bug report.


[09:03] <benonsoftware> godbyk: Ping
[09:55] <godbyk> benonsoftware: pong
[10:15] <benonsoftware> godbyk: Hi, are you the person I should talk to about a tiny daily in the glossary?
[10:15] <benonsoftware> (I'm in charge of that & index)
[10:27] <benonsoftware> godbyk: I was wondeirng if I can have a couple more days for the glossary as I'm sick at the moment?
[10:36] <godbyk> benonsoftware: Sure!
[10:36] <benonsoftware> Thank you
[10:36] <godbyk> The index and glossary can be done during the editing phase as well.
[10:36] <godbyk> (It's hard to index things when people are constantly modifying the chapter text.)
[10:36] <godbyk> Do you know how to write glossary entries and how to index things?
[10:36] <benonsoftware> Yes, I was going to wait to do that ;)
[10:36] <benonsoftware> Yeah
[10:37] <benonsoftware> (Just to let you know I'm not very good at tex)
[10:37] <godbyk> Okay, cool.  If you have any questions about it or run into any snags, let me know.
[10:37] <benonsoftware> Thanks
[10:37] <godbyk> The glossary entries are fairly easy to handle (though they give bad error messages if you screw up the syntax.)
[10:37] <godbyk> The index entries are a bit tricker because there are multiple ways to write them depending on how you want it to appear in the index.
[10:38] <benonsoftware> Okies, I'll have a look at past glossary's to see how to do it
[10:38] <benonsoftware> Yep
[10:38] <godbyk> But we can discuss that when you're feeling better and are ready to start indexing.
[10:38] <benonsoftware> Thanks
[10:38] <godbyk> No problem.
[10:38] <godbyk> Thanks for helping us out!
[10:38] <benonsoftware> :)
[15:10] <hannie> tomswartz07, are you here?


[00:00] <asac> all fine?
[00:01] <asac> bimberi: yeah. ap might not be happy with 1:
[00:01] <asac> you could also try 1:~
[00:01] <asac> Venus_Mars: the install location of components dir is not fixed
[00:02] <asac> at best wrap your component into an extension
[00:02] <Venus_Mars> I did it into extension and error console says "Failed to load XPCOM component<EMAIL_ADDRESS>[00:03] <asac> this device is really cool ;)
[00:03] <asac> just works I'd say
[00:03] <asac> Venus_Mars: i guess it wont load in xul components dir too
[00:04] <Venus_Mars> when I did a nspr logging this was the output http://pastebin.org/46632
[00:04] <asac> your component is probably wrong ;)
[00:04] <Venus_Mars> and the output of ldd -r MyComponent.so is http://pastebin.org/46634
[00:04] <asac> Venus_Mars: there is a missing symbol ;)
[00:05] <Venus_Mars> there must be some problem with compiling.. may be should change compiling flags in Makefile
[00:05] <asac> not sure. if you build with -fPIC and -shared it should probably work
[00:06] <Venus_Mars> I dint get you
[00:06] <Venus_Mars> the makefile is at http://www.it.iitb.ac.in/~nithind/src/Makefile
[00:06] <bimberi> asac: ok, trying 1:~
[00:07] <Venus_Mars> http://developer.mozilla.org/en/docs/XPCOM_Glue
[00:08] <asac> Venus_Mars: id say that its your code ;)
[00:08] <asac> Venus_Mars: yes. you get the right flags with libxul
[00:08] <asac> (XPCOM_Glue)
[00:09] <Venus_Mars> xpcom_glue shows a table which says -L/path/to/sdk/lib -lxpcomglue
[00:09] <Venus_Mars> as linker flags
[00:09] <asac> Venus_Mars: read more carefully ;)
[00:09] <asac> hint: there are two type of glues ;)
[00:10] <Venus_Mars> iam thinking to use the standalone glue. am I wrong?
[00:11] <asac> yes
[00:11] <asac> standalone is for standalone ... i dont think your component has a main method ;)
[00:14] <Venus_Mars> okie but the makefile is not using -lxpcomglue_s -lxpcom -lnspr4
[00:15] <asac> Venus_Mars: it should (pkg-config)
[00:15] <Venus_Mars> echo `pkg-config --cflags libxul`
[00:15] <Venus_Mars> -fshort-wchar -I/usr/include/xulrunner-1.9/stable -I/usr/include/nspr
[00:15] <asac> Venus_Mars: yes, but those are cflags
[00:15] <asac> what you look for here are "linker" flags
[00:16] <asac> Venus_Mars: now that i am looking, i see the problem ;) ... look closer :)
[00:16] <asac> hint: your linker flags are indeed bogus ;)
[00:16] <Venus_Mars> it should be  -L
[00:17] <Venus_Mars> ?
[00:17] <asac> what variable stand for linker flags?
[00:19] <Venus_Mars> --libs?
[00:20] <Venus_Mars> I guess I should replace --cflags with --libs
[00:20] <asac> how could you find out?
[00:20] <Venus_Mars> man pkg-config
[00:22] <asac> one way ;) not sure if that tells you everything :)
[00:23] <asac> man, give it a try ... go
[00:23] <Venus_Mars> am I missing anything more?
[00:24] <asac> cant tell
[00:24] <Venus_Mars> Well I tried, still its not able to load
[00:24] <Venus_Mars> :(
[00:24] <asac> are linker flags correct now?
[00:24] <asac> same issue or something else
[00:25] <Venus_Mars> http://pastebin.org/46639
[00:25] <Venus_Mars> the output of ldd -r MyComponent.so
[00:26] <asac> thats not really meaningful as you cannot even resolve libxul and libxpcom
[00:27] <Venus_Mars> yeah, so what can be done about libxul.so?
[00:27] <asac> looking for compiler warnings would be a good start
[00:27] <asac> Venus_Mars: thats not your problem
[00:27] <asac> you have to look elsewhere
[00:27] <asac> you just cant use ldd -r that way
[00:27] <Venus_Mars> I dint get compiler warnings
[00:28] <Venus_Mars> what should I do ?
[00:29] <asac> whats the error you are getting ;)
[00:29] <asac> did you install all files required?
[00:29] <Venus_Mars> symbol missing
[00:29] <Venus_Mars> No, firefox is failing to load the component
[00:30] <asac> so which files did you install where?
[00:31] <Venus_Mars> I am installing through extension
[00:31] <Venus_Mars> I have created  components dir in my extension rootdir and then copied MyComponent.so in  components
[00:31] <Venus_Mars> and the bundle it into .xpi
[00:32] <Venus_Mars> and then I open it with firefox
[00:33] <Venus_Mars> Am I meaningful?
[00:33] <asac> install  the .xpt as well
[00:34] <Venus_Mars> Yeah I have included IMyComponent.xpt as well
[00:39] <Venus_Mars> well my plugin is accessible www.it.iitb.ac.in/~nithind/firefox-extension
[00:39] <Venus_Mars> I mean the extension
[00:41] <Venus_Mars> still no clue?
[01:36] <bimberi> asac: "Conflicts: j2re1.4 (<< 1:~)" works too.
[01:54] <Venus_Mars> asac: I have figured it out finally
[01:54] <Venus_Mars> there is one forum which suggest for changed in the linking order
[01:54] <Venus_Mars>  $(FILES) $(GECKO_SDK_PATH)/lib/libxpcomglue_s.a $(GECKO_LDFLAGS)
[01:54] <Venus_Mars> this linking order could make the undefined symbols vanish
[01:54] <Venus_Mars> Its a magic
[05:36] <jetsaredim> anyone know why on kubuntu html form fields don't have any borders in firefox 3?
[08:33] <Kamping_Kaiser> hi :)
[08:34] <Kamping_Kaiser> in the $PROJECT.mk file theres a MOZCLIENT_FILE which contains the project version - what is that path relative to?
[08:45] <Kamping_Kaiser> (i'm kgoetz from before, incase anyone wasnt aware :)). i'm still finding it all mildly confusing.
[10:00] <gnomefreak> asac fta_ and/or Jazzva the HTML Validator needs to be discussed as i just got done reading an email about it, please get in touch with me so we can decide if this is something we really want to add.
[10:01] <gnomefreak> well i guess nevermind i didnt see asac's post to it
[10:04] <gnomefreak> asac: when are we adding NM0.7 or are we not going to? As i understand it is stable or will be shortly
[10:12] <Jazzva> asac, I'll be back around 18h... off to the exam.
[10:12] <Jazzva> If all of you decide we don't need htmlvalidator, I'm fine with that :)
[10:13] <Jazzva> see ya later
[10:17] <gnomefreak> personally i dont like the amount of work that would be involved. I thought xulrunner was for plugins not so much extensions, im sure we can get it to work but packaging them separate i feel is better than adding it to build in a package
[10:27] <gnomefreak> [reed]: your last name isnt Friedman, please say no!
[11:08] <gnomefreak> whos here?
[11:51] <gnomefreak> i think we can trash htmlvalidator due to the way it needs to be packaged and it is missing any license and nowher eon any of its upstream pages says anything about a license. I added post on bug report for someone to email upstream <gave email address> so please feel free to email him
[12:23] <fta> Kamping_Kaiser: MOZCLIENT_FILE is relative to the VCS dir, except if you requested a MOZDIR
[12:23] <gnomefreak> rzr: you didnt get the email about mozillsquad due to not having email address on LP page. so i might make a note on the page to include a comment like that
[12:24] <gnomefreak> damn i havent seen that name in ages
[12:24] <gnomefreak> hes been using his other one
[12:25] <gnomefreak> does anyone happent o knwo the file to edit start up processes like bluetooth and trackerd ect...
[12:28] <Kamping_Kaiser> fta, thanks
[12:29] <fta> Kamping_Kaiser, could you paste your .conf ?
[12:30] <Kamping_Kaiser> fta, i havent made any changes yet, just trying to understand the firefox-3.0.conf before i do
[12:31] <Kamping_Kaiser> except when i try and find it in the mozilla-devscripts source package i cant see it :/ only in bzr
[12:32] <fta> yep, i've refactored mozclient in mozilla-devscripts and it's not released yet. it will be in 0.09
[12:32] <fta> asac, i want to release 0.09 ^^ wanna sponsor me ?
[12:34] <Kamping_Kaiser> ah, i see. is firefox-3.0.mk.in the correct file to edit if i'm editing the 0.7 source package?
[12:34] <gnomefreak> fta: can you add sunbird 0.9 to devscripts please. its about to release rc1 and i would like to get it in PPA for testing
[12:35] <fta> gnomefreak, i already have lightning-sunbird
[12:35] <gnomefreak> it will grab rcs?
[12:35] <fta> yes
[12:35] <gnomefreak> oh ok i thought it was just stable
[12:35] <fta> from MOZILLA_1_8_BRANCH
[12:35] <gnomefreak> ah ok
[12:35] <fta> doesn't matter, use the proper CVS TAG
[12:36] <gnomefreak> k
[12:36] <fta> that way, it's the same as fetching a tarball and repacking it
[12:37] <gnomefreak> yep i like devscripts for that reason including nobinonly ;)
[12:39] <Kamping_Kaiser> firefox-3.0.mk.in is quite a bit longer (and more complex) then firefox-3.0.conf :\
[12:40] <fta> you'd better use 0.09 from bzr otherwise you will have to redo everything once it's released
[12:41] <gnomefreak> fta: that was for Kamping_Kaiser right?
[12:41] <fta> gnomefreak, yes
[12:42] <Kamping_Kaiser> fta, hm, ok.
[12:42] <fta> Kamping_Kaiser, it should be similar, except the wrapped lines
[12:43] <Kamping_Kaiser> fta, so i need to customise m-d and instlal the package, then i can use the custom .conf from my new m-d to build a customised FF3 - is that correct?
[12:46] <fta> well, you only used touched the mozclient part of m-d so it should not me needed to build, just to create the tarball
[12:46] <fta> -used
[12:51] <Kamping_Kaiser> !pastebin
[12:53] <Kamping_Kaiser> re paste of my .conf: only one line in it so far - http://paste.ubuntu.com/23495
[12:53] <Kamping_Kaiser> some lucky person is 8 away froma  23456 get
[12:53] <Kamping_Kaiser> *11
[12:55] <fta> Kamping_Kaiser, so you only changed MOZCLIENT_APPNAME right ?
[12:55] <Kamping_Kaiser> fta, yes.
[12:55] <Kamping_Kaiser> i /just/ made the change (i havent worked on this at all today)
[13:01]  * Kamping_Kaiser changes copyright notice
[13:02] <gnomefreak> can i use mozdate and mozbranch?
[13:03] <fta> yes
[13:04] <fta> gnomefreak, what do you want to do ?
[13:04] <gnomefreak> for sunbird 0.9
[13:04] <fta> use a tag
[13:04] <fta> not a date
[13:05] <gnomefreak> ok and i still neeed branch right?
[13:05] <fta> yes
[13:05] <fta> in fact no, it's in the project file by default
[13:06] <fta> but there's no sunbird 0.9 tag yet
[13:06] <gnomefreak> so no way to grab it?
[13:06] <gnomefreak> i miss the old readme file
[13:06] <fta> http://paste.ubuntu.com/23501/
[13:07] <gnomefreak> so i guess im waiting
[13:07] <fta> was it announced ?
[13:07] <gnomefreak> i got an announcement that rc1 will be released in a day or 3
[13:08] <gnomefreak> i dont remember exact date. but string freeze is now
[13:08] <gnomefreak> one of the 100 mozilla mailing lists im on
[13:08] <gnomefreak> i want to say it was dev-app mailing list
[13:09] <gnomefreak> does it have to be announced if its on ftp.mozilla?
[13:10] <fta> oh, i saw the string freeze too but it doesn't mean the tag is there
[13:10] <fta> yes, i guess the sunbird team will blog about it
[13:10] <fta> is it just me or grep -i is broken in intrepid ?
[13:12] <fta> http://paste.ubuntu.com/23503/
[13:13] <Kamping_Kaiser> fta, i've created a new .conf file (in src/mozclient/), do i need to create a new .mk.in?
[13:13] <fta> yes, and edit the Makefile accordingly
[13:14] <fta> the .mk file is only useful if you want a get-orig-source in your debian/rules
[13:15] <gnomefreak> fta: works here gnomefreak@Development:~$ echo FOOBAR | grep -i FOO
[13:15] <gnomefreak> FOOBAR
[13:15] <gnomefreak> atleast that is working afaict
[13:15] <gnomefreak> oh nevermind it should be in lowercase
[13:15] <fta> no
[13:16] <gnomefreak> it should because -i == ignores case
[13:17] <fta> no, it should stay untouched
[13:17] <fta> must
[13:17] <gnomefreak> atleast according to --help
[13:17] <gnomefreak> -i, --ignore-case         ignore case distinctions
[13:17] <fta> yes
[13:17] <gnomefreak> define untouched
[13:18] <gnomefreak> your pastebin Hardy is how it should be right?
[13:18] <fta> but ignore case during the test, but the output is not transformed, just filtered
[13:18] <fta> yes
[13:18] <gnomefreak> well my intrepid works that way
[13:18] <gnomefreak> so i would have to say it works
[13:18] <gnomefreak> fta@cube:~ $ echo FOOBAR | grep -i FOO
[13:18] <gnomefreak> FOOBAR
[13:19] <gnomefreak> that is how it should output it
[13:19] <fta> yes
[13:19] <gnomefreak> intrepid for me
[13:19] <gnomefreak> gnomefreak@Development:~$ echo FOOBAR | grep -i FOO
[13:19] <gnomefreak> FOOBAR
[13:19] <gnomefreak> Host 'Development', running Linux 2.6.26-2-generic - Cpu0: Intel 1681 MHz; Up: 3:48; Users: 4; Load: 0.11; Free: [Mem: 26/248 Mio] [Swap: 605/729 Mio] [/: 23913/38173 Mio]; Vpenis: 36.2 cm;
[13:20] <gnomefreak> fta: you have this version of grep? 2.5.3~dfsg-5ubuntu
[13:20] <gnomefreak> 2.5.3~dfsg-5ubuntu1
[13:20] <fta> yes
[13:20] <gnomefreak> sorry didnt paste the 1
[13:21] <gnomefreak> not sure why yours isnt working
[13:21] <gnomefreak> im guessing you did todays 6 packages but grep wasnt one of them IIRC
[13:21] <gnomefreak> The following NEW packages will be installed: discover discover-data libdiscover2
[13:21] <gnomefreak> The following packages will be upgraded: debhelper debianutils gdebi gdebi-core hotkey-setup xserver-xorg-video-ati xserver-xorg-video-radeon
[13:21] <gnomefreak> those packages?
[13:22] <fta> it's been broken for days
[13:22] <gnomefreak> hmmmm
[13:22] <gnomefreak> it works without -i for you
[13:22] <fta> yes
[13:22] <gnomefreak> do the rest of the flags work?
[13:23] <gnomefreak> or atleast some of them (theres a crap load of flags to use)
[13:23] <fta> yes
[13:23] <fta> fta@ix:~ $ echo FOOBAR | grep -v FOO
[13:23] <fta> fta@ix:~ $ echo FOOBAR | grep -c FOO
[13:23] <fta> 1
[13:23] <gnomefreak> fta: what happens if you use ' around FOO
[13:23] <fta> no difference
[13:23] <fta> i've already tested tons of stuff
[13:24] <fta> i guess it's a locale issue
[13:24] <fta> but i can't see what's wrong
[13:25] <gnomefreak> it shouold affect other flags unless you built your own/hacked it?
[13:26] <fta> i didn't
[13:26] <gnomefreak> i dont see why you would hack or build grep because honestly it already is full of crap
[13:27] <gnomefreak> it works if you use real files?
[13:27] <gnomefreak> oh thanks for reminding me to look stuff up
[13:28]  * gnomefreak didnt know what an ibex is until just now and it looks like ill never see one :(
[13:30] <fta> 66-match_icase.patch
[13:31] <fta> This fixes
[13:31] <fta>     echo Y | LC_ALL=en_US.UTF-8 grep -i '[y]'
[13:31] <fta> The expected output is:
[13:31] <fta>     Y
[13:31] <fta> Without this patch, it works on non UTF-8 environment, but fails on UTF-8
[13:31] <fta> environment.
[13:31] <fta> fta@ix:~$ echo Y | LC_ALL=en_US.UTF-8 grep -i '[y]'
[13:31] <fta> fta@ix:~$
[13:34] <fta> gnomefreak, does it work for you ?
[13:34] <fta> intrepid
[13:34] <gnomefreak> no outpu
[13:34] <gnomefreak> t
[13:35] <fta> are you using utf8 as locale ?
[13:35] <gnomefreak> gnomefreak@Development:~$ echo Y | LC_ALL=en_US.UTF-8 grep -i '[y]'
[13:35] <gnomefreak> gnomefreak@Development:~$
[13:35] <fta> $ echo $LANG
[13:35] <fta> en_US.UTF-8
[13:35] <gnomefreak> lol
[13:35] <gnomefreak> C
[13:36] <gnomefreak> not sure where the hell that came from
[13:36] <gnomefreak> gnomefreak@Development:~$ echo $LANG
[13:36] <gnomefreak> C
[13:37] <fta> ok, so it was expected
[13:37] <fta> fta@ix:~$ echo Y | LC_ALL=C grep -i '[y]'
[13:37] <fta> Y
[13:39] <gnomefreak> i get Y
[13:39] <fta> i guessed ;)
[13:42] <fta> debian bug 387704
[13:43] <gnomefreak> oh i think im C because i have it in .bashrc to get rid of locale errors/warnings in my chroots (i found no other way to apply it only to chroots
[13:44] <fta> i correctly setup locales in chroots too
[13:49] <fta> bug 243717
[15:09] <asac> hi
[15:10] <fta> hi
[15:11] <asac> fta: so 0.09?
[15:11] <fta> asac, it's stable enough for my taste, and already big
[15:12] <fta> i'm ready to close it if you want to sponsor me
[15:12] <Volans> Hi asac :)
[15:12] <asac> fta: typo: "taggued mozilla/client.mk"
[15:13] <fta> where?
[15:13] <armin76> bumbed
[15:13] <asac> oh wait let me pull the latest :)
[15:13] <asac> fta: you still appear to like "uncommitting" :) ... diverged
[15:14] <fta> i sometimes do that in the next second when i realize something is wrong, but not later
[15:15] <asac> fta: well. but i had the uncommitted change ;)
[15:15] <asac> so either i pulled in that second or you waited longer ;)
[15:15] <asac> the changelog is incredible long
[15:16] <asac> not really useful
[15:16] <asac> imo
[15:16] <asac> i think we could make one entry for all the new VARAIBLES
[15:16] <asac> another for all added VCS backend
[15:16] <asac> another for all added projects
[15:17] <fta> as i said, it's big, i wanted this in long ago
[15:17] <asac> yeah. still the content could be compressed to something comprehensible ;)
[15:17] <asac> anyway. can do it that way
[15:18] <asac> fix the typo inthe changelog if you want ;)
[15:18] <asac> oh even two times taggued ;)
[15:18] <fta> fixed
[15:19] <asac> fta: have you tested it?
[15:19] <fta> sure
[15:19] <asac> fta: i think what we want for 0.10 is kind of make check ;)
[15:20] <asac> e.g. that produces several origs, etc.
[15:20] <fta> ?
[15:20] <fta> explain
[15:20] <asac> test-cases
[15:20] <asac> that we can run with make check
[15:20] <fta> oh
[15:20] <armin76> !info libnss3 intrepid
[15:20] <fta> -0d
[15:20] <armin76> !info libnss intrepid
[15:20] <armin76> bah
[15:20] <asac> i dont feel in the position to test each and every combination of project/backend anymore :)
[15:20] <asac> which means its time to do automated tests
[15:21] <asac> !info libnss3-0d
[15:21] <asac> !info libnss3-1d
[15:21] <armin76> fta: bumb!
[15:22] <armin76> when are you guys going to fix the ppc segfault? :P
[15:23] <asac> armin76: we rely on contributions for that
[15:23] <armin76> just make it compile with -O1
[15:24] <armin76> looks like its a bug on glibc or something, because i've been told that guile and glibc-2.8 do the same on ppc
[15:32] <asac> fta: you think you can come up with a basic script that gets latest xpi for a given AMOID from addons.mozilla.org before your leave?
[15:32] <asac> that would help us a lot to setup new upstream branches manually i guess
[15:32] <fta> possible
[15:32] <asac> and can certainly be reused in the final auto syncher
[15:33] <asac> fta: so whats your idea about how to code this? parse HTML?
[15:33] <Volans> asac, fta can I help in some way for that?
[15:33] <asac> Volans: yeah. what we need is a simple script that gets latest .xpi for a given AMOID from addons.mozilla.org
[15:33] <asac> i think one way would be to parse the website
[15:34] <asac> but i think there is a smarter way
[15:34] <Volans> yes for sure... I will try
[15:34] <asac> as firefox queries addons.mozilla.org as well, there probably exists an xml interface
[15:36] <fta> http://paste.ubuntu.com/23524/ better ?
[15:36] <Volans> asac: I have found that if you do:
[15:36] <asac> http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsAddonRepository.js
[15:36] <Volans>  wget https://addons.mozilla.org/it/firefox/downloads/file/AMOID/
[15:36] <asac> thats the code that queries addons
[15:36] <Volans> it download the last public version
[15:36] <Volans> after some redirect
[15:37] <asac> fta: definitly more compressed. though mostly just the file references missing i guess
[15:38] <fta> that doubles the size
[15:38] <fta> people could still read bzr logs or code.lp
[15:38] <asac> yeah. thats ok
[15:38] <asac> i mean i woudl have been fine with the other changelog too. but this is better
[15:39] <asac> fta: i guess you have Vcz-Bzr in control?
[15:39] <fta> yes
[15:39] <asac> maybe add it as reference to copyright too (if not already done)
[15:39] <asac> and README ;)
[15:39] <asac> Volans: why "it" :)
[15:39] <asac> ?
[15:40] <asac> can i replace that with nothing? or "en"?
[15:40] <Volans> sorry... I was visiting with browser and auto localizations o mozilla site ;)
[15:40] <asac> Volans: so what is the genuine URL to use for that?
[15:40] <Volans> let me try
[15:41] <fta> asac, closed & pushed
[15:41] <asac> gbood
[15:42] <asac> doing some basic tests and will upload if those work ;)
[15:42] <fta> i want to change that: http://mxr.mozilla.org/mozilla/source/browser/app/Makefile.in#429
[15:43] <asac> that specific line or that area?
[15:43] <fta> not sure if we want to set SKIP_COPY_XULRUNNER or patch to make a symlink or something else
[15:43] <fta> for xulapps
[15:43] <fta> there's no way to pass SKIP_COPY_XULRUNNER from configure, or at least i don't know of any
[15:44] <asac> fta: what do you want to prevent?
[15:44] <fta> ship a full copy of xulrunner in each xulapp
[15:45] <asac> ok the SKIP_COPY_XULRUNNER
[15:45] <asac> so how is it set atm?
[15:45] <asac> or is it just a "not-used" feature?
[15:45] <fta> this is prism with my new build system: http://paste.ubuntu.com/23529/
[15:47] <Volans> asac: finally  wget  https://addons.mozilla.org/en-US/downloads/file/AMOID/ works, but wget made 3 redirect before download the final file on order to autodetect the destination program (FF, TB, SM) and the name of the latest file to be downloaded
[15:47] <asac> Volans: hm
[15:47] <asac> m
[15:47] <Volans> if you use HTTP instead of HTTPS he made another redirect... I don't know why he continues do https and http request
[15:48] <fta> asac, SKIP_COPY_XULRUNNER is nowhere else, just in this test
[15:48] <asac> fta: ok, so its a left-over
[15:48] <asac> fta: have you tested that setting it actually works?
[15:48] <Volans> what trouble you asac, too much redirect?
[15:49] <fta> no, according to blame, it has been added in one shot with mozilla bug 390361 and the whole block never changed since
[15:49] <fta> they want the xulapp to be independent of xul at runtime
[15:50] <fta> i don't think we want that
[15:50] <asac> yes. i understand that pov
[15:50] <asac> fta: depends
[15:50] <asac> fta: what kind of dependence do we need?
[15:51] <Volans> the final link asac is something like this:  http://releases.mozilla.org/pub/mozilla.org/addons/AMOID/FILENAME-APP.xpi
[15:51] <Volans> whit APP = 'fx' for firefox and similar... but you have to find the correct FILENAME! without dosn't work
[15:51] <fta> in our ff3 package, I patched it to set SKIP_COPY_XULRUNNER long ago
[15:51] <fta> that's installer_shouldnt_copy_xulrunner.patch
[15:52] <fta> we will need xulrunner-1.9 as dep, like ff3
[15:53] <asac> fta: ok. but we still copy the stub right?
[15:53] <fta> asac, ^^, or we can let each xulapp decides
[15:53] <fta> yes
[15:54] <asac> i think firefox is somewhat special
[15:55] <Volans> asac: wait I have found it! :D
[15:55] <Volans> for example: http://releases.mozilla.org/pub/mozilla.org/addons/3863/
[15:55] <Volans> open it in browser
[15:55] <Volans> is a watchable folder!
[15:55] <asac> note that I am with you with the point that we want to skip xulrunner copies
[15:56] <asac> Volans: good
[15:56] <asac> thats nice
[15:56] <Volans> and I can assure you that there are only public versions... I have one waiting for approval and it is not in list
[15:57] <Volans> then watching http://releases.mozilla.org/pub/mozilla.org/addons/AMOID/ can be the best choice if you want to avoid automatic redirect from addons.mozilla.org site
[15:59] <asac> Volans: ok you can get the version, by: xpath  -q -e '/RDF/Description/em:version/text()' install.rdf
[15:59] <asac> and if that fails its an attribute of Description:
[15:59] <fta> asac, worse case, i can add a symlink in an "else" block.. it will then be in ff3 too but that shouldn't hurt
[16:00] <asac> /RDF/Description/@em:version
[16:00] <fta> hm, no. the symlink will not survive xul updates
[16:01] <Volans> asac: you want to made this check after download the xpi file that we suppose to be the latest?
[16:03] <asac> Volans: no. i want two scripts: 1st. download-latest <AMOID> <TARGET_DIR>
[16:03] <asac> 2nd. get-xpi-info VERSION <XPI_FILE>
[16:03] <Volans> bash script?
[16:03] <asac> get-xpi-info NAME <XPI_FILE>
[16:03] <asac> Volans: whatever ;)
[16:04] <Volans> fta: you are already working on that or I can start from scratch?
[16:04] <fta> i'm already working on that
[16:05] <asac> fta: so can you give us download-latest?
[16:05] <asac> ;)
[16:05] <Volans> I can help you in some way?
[16:05] <fta> not at that point, it's still half in my brain
[16:06] <Volans> and in you files? :)
[16:06] <fta> but if you think i'm too slow, go ahead, i'll drop the ball
[16:06] <asac> fta: its just about the two scripts :)
[16:07] <fta> get-xpi-info is currently something that is in my old shell script
[16:07] <fta> but i wanted a class in the main framework
[16:07] <fta> instead of a shell script
[16:07] <asac> fta: ok. we dont need get-xpi-info now
[16:08] <asac> what i want is basically just download-latest
[16:08] <Volans> fta:  in what language you are writing the framework?
[16:08] <fta> Volans, OO perl
[16:08] <fta> like mozclient
[16:08] <fta> maybe even cleaner
[16:09]  * Volans never coded in perl....
[16:09] <fta> with external plugins in any langage
[16:09] <asac> fta: did you review the config branch?
[16:09] <fta> yes, i had questions but you were offline
[16:09] <asac> fta: still have them in your mind?
[16:10] <fta> hm, nope, i'll have another look later today, after i'm back from sports
[16:10] <asac> fta: so what interface would a download-latest plugin have? isnt download-latest-amo <BRANCHID> <TARGET_DIR) ok?
[16:11] <asac> or would it rather be generic download <CONFIG_DIR>
[16:11] <asac> maybe with <VERSION> == LATEST if ommitted
[16:12] <Volans> asac: where this framework should run? (server based, your pc, etc...)
[16:12] <asac> Volans: we have a semi-spec for that
[16:13] <asac> Volans: it should not matter where its run in the end
[16:13] <asac> its just that it need permissions to proper branches
[16:13] <asac> https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/LargeScaleMaintenance
[16:14]  * Volans looks
[16:14] <fta> Volans, by framework, i mean a set of classes used by all the binaries, to parse conf files, do amo parsing, do xpi parsing, do branch management, etc
[16:14] <asac> Volans: the current focus is on the "Auto Updater"
[16:15] <asac> which consists of two parts: "auto upstream branch synchs"
[16:15] <asac> and "auto branch merging"
[16:15] <Volans> ok
[16:15] <asac> we could talk about both as "tasks"
[16:15] <asac> for the syncher ;)
[16:15] <asac> aka BOT
[16:16] <asac> so we have a configuration format proposal here:
[16:16] <asac> https://code.edge.launchpad.net/~mozillateam/firefox-extensions/BOT.TASKS
[16:16] <asac> thats the configuration tree we would give the bot
[16:16] <asac> (just a first pitch)
[16:17] <asac> the idea is that you can run the bot with a task config: bot upstream/amo/firefox-3.0.HEAD
[16:17] <asac> err firebug.HEAD :)
[16:18] <asac> and the bot would know about all the magic to sync the upstream branch
[16:18] <asac> by loading plugins and so on
[16:19] <asac> the configuration is a tree configuration. the bot would first load upstream/config, then load upstream/amo/config and then would load upstream/amo/firebug.HEAD config to get the complete configuration.
[16:20] <asac> just look at the files in the BOT.TASKS branch
[16:21] <Volans> I understand... only a question: why not to do a separate bot only for sync with AMO xpis that run on cron and alert you and all the people needed when a new upstream version is out?
[16:22] <asac> Volans: we dont want to alert everyone that new upstream version is out, we want to alter the right people that there is a new merge ready to be signed off / or that needs manual interaction
[16:22] <Volans> then all the BOT will run on a cron basis...
[16:22] <Volans> s/all/the whole/
[16:24] <asac> Volans: yes.
[16:24] <asac> the bot would basically run over the config tree and process each config file (which represents a task)
[16:25] <Volans> you can made a choice that I think is no very restrictive... insert the basename of the xpi in the config file
[16:25] <asac> Volans: why?
[16:25] <asac> we just need AMOID
[16:25] <asac> Volans: look at the config file . there already is a name for the upstream branch.
[16:26] <Volans> when I upload a new version of my extension on AMO site... the site will change the name automatically based on extension name and version adding also a APPLICATION suffix at the end, maybe can help for finding the latest version
[16:29] <asac> Volans: if its required we can add it. just hoped there is something that doesnt require us to intepret the version
[16:30] <fta> leaving for 2h~3h. please write down your ideas & concerns
[16:30] <fta> c u
[16:31] <Volans> asac: problem... I have found a AMOID not present in oregon state archive...
[16:31] <Volans> damnit
[16:31]  * Volans doing random tests to verify if it works in every case
[16:33] <Volans> sorry.... my fault I have used fileid instead of AMOID... works! :D
[16:33] <asac> Volans: i have written a protoype bot that reads the config hierarchy
[16:33] <asac> https://code.edge.launchpad.net/~mozillateam/firefox-extensions/BOT
[16:34] <asac> runtask is a shell script that parses the config as specified
[16:34] <asac> and runs the task plugin found for the config
[16:34] <asac> e.g. in the example its "UPSTREAM"
[16:35] <Volans> yeah I see
[16:35] <asac> so you run runtask upstream/amo/flashblock.ubuntu.HEAD
[16:35] <asac> to test ;)
[16:37] <asac> should probably be AMO_UPSTREAM ;)
[16:38] <asac> or UPSTREAM will exists and uses GET_LATEST_AMO + UPDATE_BZR_TREE
[16:38] <asac> :)
[16:38] <asac> most likely thats the right idea ;)
[16:39] <Volans> ok, I'm reading the sh script... you write bash with different style
[16:39] <asac> most likely. never really tried to look for "clean" scripting ;)
[16:40] <Volans> no is clear... only tests... I use [] in if and other tests... you the "test" statement
[16:40] <asac> yeah
[16:41] <asac> Volans: i am always confused by what is available in which sh-dialect
[16:41] <asac> so i use what appears to be "most" primitive ;)
[16:41] <asac> without actually knowing anything ;)
[16:44] <Volans> correct... I use always bash not sh... but just for "habitude!
[16:44] <Volans> "
[16:44] <asac> so runalltasks would basically just be: "find -type f /path/to/BOT.TASKS/ | grep -v config$"
[16:44] <asac> err flip arguments of find obviously :)
[16:45] <Volans> or better making a config file with all the BOT.TASK files and parse it line per line
[16:45] <asac> find -type f /path/to/BOT.TASKS/ | grep -v config$ | xargs runtask
[16:45] <Venus_Mars> hi Volans
[16:45] <asac> flipped again
[16:45] <Volans> hi Venus_Mars
[16:46] <Volans> asac: in order to test it I have to download also a task tree from the previous branch?
[16:48] <Volans> (~mozillateam/firefox-extensions/BOT.TASKS)
[16:48] <asac> Volans: no that happens automatically iirc
[16:48] <asac> yes: bzr branch $ENV_TASKS_BRANCH $tasksconfigdir
[17:06] <Volans> asac: sorry, probably I don't have understand something... I run:  ./runtask upstream/amo/config
[17:07] <asac> Venus_Mars: btw, i found a better example for you :)
[17:07] <Volans> or  ./runtask upstream/amo/flashblock.ubuntu.HEAD with different results
[17:07] <asac> http://developer.mozilla.org/en/docs/Creating_XPCOM_Components:Using_XPCOM_Utilities_to_Make_Things_Easier
[17:07] <asac> just get the webblock.cpp
[17:07] <asac> and build it like:
[17:08] <asac> gcc -o /usr/lib/xulrunner-1.9/components/libnssample.so -shared -fPIC nsSample.cpp `pkg-config --cflags --libs libxul`
[17:08] <asac> (with sudo ;))
[17:08] <asac> well nsSample.cpp is webblock.cpp ;)
[17:08] <asac> weblock2.cpp ;)
[17:08] <asac> hehe
[17:09] <Venus_Mars> Yeah I got this link yesterday but was almost exhausted...
[17:09] <Venus_Mars> Yeah today I may try with more experiments
[17:09] <asac> Venus_Mars: just try that ;)
[17:09] <asac> then you can use:
[17:09] <asac> sh /usr/lib/xulrunner-1.9/run-mozilla.sh /usr/bin/xpcshell-1.9
[17:09] <asac> js> Components.classes['@company.com/sample'].createInstance()
[17:09] <asac> [xpconnect wrapped nsISupports]
[17:09] <asac> ;)
[17:10] <Venus_Mars> yeah sure....
[17:11] <asac> after that, stop reinventing the wheel and code you xpcom components in a proper build system where you dont have to fight things you dont want to fight
[17:11] <Venus_Mars> heh
[17:11] <Venus_Mars> yeah
[19:05] <Venus_Mars> asac: want some examples where an extension can you upload files
[19:19] <Volans> Venus_Mars: the site where it can upload or what?
[19:20] <Venus_Mars> upload files to a site
[19:21] <Volans> I don't have undestand you question Venus_Mars.... what kind of examples you want?
[19:21] <Venus_Mars> a javascript which ll upload a local file to a remote system
[19:22] <Volans> you don't have already found such similar extensions?
[19:22] <Volans> (iirc in the past talk we had)
[19:23] <Venus_Mars> well, their code involves lot of classes...simply untraceable
[19:40]  * Volans dinner time... come back later
[19:56] <Jazzva> does anyone know if gnomefreak set the membership for ubuntu-mozillasquad to auto-expire one month after joining the team?
[19:59] <[reed]> do members of MozillaTeam _have to_ get e-mail for everybody that joins ubuntu-mozillasquad?
[19:59] <[reed]> :(
[20:10] <armin76> haha
[20:14] <armin76> asac: i wonder if the sparc segfault could be related to some -O flag...-O3?
[20:14] <armin76> s/segfault/bus error
[20:20] <armin76> nope
[20:21] <armin76> i've rebuilt it using mozilla's default and it doesn't give bus error here
[20:28] <Jazzva> [reed], Mozilla Team is the owner of ubuntu-mozillasquad so far... So, I suppose the answer is yes. Maybe it can be turned off somewhere, or something. :)
[22:29]  * Volans back.... :)