[08:45] <AlanBell> anyone rushing out to buy a project sputnik laptop?
[08:47] <AlanBell> I am struggling to believe how badly that project has been handled, it is as if someone was intentionally engineering it to have low sales figures
[08:48] <AlanBell> lets take an awesome laptop, announce we are releasing it with Ubuntu, then wait until the hardware is a year old and competition has better specs for less money
[08:49] <AlanBell> then sell it for a $50 premium over the windows equivalent
[08:49] <AlanBell> so they are going to say "yeah, we tried an Ubuntu laptop, people talked about it, but nobody bought it, so we won't do that again"
[11:17] <jussi> AlanBell: yeah, I wont be buying one...
[12:39] <Tm_T> AlanBell: I'm unsure should I ask it for my next work laptop or something else
[12:40] <Tm_T> there's couple reasons why I wouldn't want it, for example AFAIK it doesn't have docking bay capability


[11:38] <Keybuk> morning
[11:38] <Keybuk> ion_: around?
[11:49]  * Keybuk needs to bounce an idea off someone :p
[13:15] <ion_> keybuk: Yeah
[13:15] <Keybuk> ion_: so I've been thinking about the whole problem of job environment
[13:15] <Keybuk> let's use the getty job as an example
[13:16] <Keybuk>   env SPEED 38400
[13:16] <Keybuk>   instance $TTY
[13:16] <Keybuk>   exec /sbin/getty $SPEED $TTY
[13:16] <Keybuk> we can fire off a couple of these for the system consoles
[13:16] <Keybuk>   start getty TTY=tty1
[13:16] <Keybuk>   start getty TTY=tty2
[13:16] <Keybuk>   start getty TTY=tty3
[13:16] <Keybuk> and we can figure up one for a slower serial console
[13:16] <Keybuk>   start getty TTY=ttyS0 SPEED=14400
[13:17] <Keybuk> environment from the start request overrides that from the job definition, so env sets "defaults"
[13:18] <Keybuk> so that all works nicely
[13:18] <Keybuk> now, what happens when another job uses those events
[13:18] <Keybuk>   start on started getty
[13:18] <Keybuk> which getty?  there's lots of gettys running
[13:18] <Keybuk> we do have the INSTANCE variable in that event we could use
[13:19] <Keybuk>   start on started getty INSTANCE=tty1
[13:19] <Keybuk> and that happens to work for this
[13:20] <Keybuk> so using a different example, the dbus session bus daemon service
[13:20] <Keybuk>   instance $USER
[13:20] <Keybuk>   exec /sbin/dbus-daemon --session
[13:20] <Keybuk>   env DBUS_SESSION_BUS_ADDRESS=...
[13:20] <Keybuk> another job might do
[13:20] <Keybuk>   start on started dbus-session-bus
[13:21] <Keybuk> but it doesn't have access to the session bus address
[13:21] <ion_> Yeah
[13:21] <Keybuk> since it exists in the job environment of the dbus-session-bus job
[13:21] <Keybuk> and isn't in the starting/started/stopping/stopped events
[13:21] <Keybuk> even getty starts to have a useful example
[13:21] <Keybuk>   start on starting getty TTY=ttyS*
[13:22] <Keybuk>   exec setserial $TTY $SPEED
[13:22] <Keybuk> suddenly we have a case where we might want to run setserial if we're starting a getty with a particular $TTY (rather than just instance name) and want the speed
[13:23] <Keybuk> so I was thinking about adding the whole job environment to the events
[13:23] <Keybuk> but I don't think that works at all
[13:23] <Keybuk> in particular, if the job's started on a failed event, any job starting on that would be indistinguishable from the same failed event info
[13:23] <Keybuk> and it just leads to massive environment creep
[13:24] <Keybuk> so what I came up with was:
[13:24] <Keybuk>   env SPEED=38400
[13:24] <Keybuk>   instance $TTY
[13:24] <Keybuk>   export TTY SPEED
[13:24] <Keybuk>   exec /sbin/getty $SPEED $TTY
[13:24] <Keybuk> ie. a job definition can "export" some of its environment
[13:24] <Keybuk> and those are the variables that will be added to its starting/started/stopping/stopped events automatically
[13:24] <ion_> Looks good
[13:25] <Keybuk> do you think that's better than exporting nothing or exporting everything?
[13:26] <ion_> Exporting everything would work, too, if the other jobs acting on those events can select what to import instead of having their environment polluted.
[13:26] <Keybuk> yeah, but I couldn't think of a good syntax from that
[13:26] <Keybuk> and that would start to mean you need to declare import for everything
[13:26] <ion_> Yeah
[13:27] <Keybuk> start on tty-added
[13:27] <ion_> What you proposed seems good to mee.
[13:27] <ion_> me
[13:27] <Keybuk> stop on tty-removed TTY=$TTY
[13:27] <Keybuk> import TTY from tty-added
[13:27] <Keybuk> (you'd need the latter to be consistent)
[13:27] <Keybuk> I kinda like the fact that if you mention an event, you automatically get its environment
[13:27] <Keybuk> and having consistency between what you can match on and what you can use is nice too
[13:28] <ion_> Yeah
[14:25] <Keybuk> of course, _now_ I notice a problem with taking away job ids
[14:25] <Keybuk> jobs with just "instance" can't be uniquely dealt with
[15:08]  * Keybuk tries to think of a reason to support unlimited instance jobs
[15:23] <Keybuk> can't think of a good one
[15:23] <Keybuk> if people really want them, they can just do something like
[15:23] <Keybuk> instance $UUID
[15:23] <Keybuk> start job UUID=$(uuidgen)
[15:31] <ion_> Yeah
[15:33] <Keybuk> after racking my brain I can't think of _any_
[15:33] <Keybuk> if it acts on an event, it needs at least one environment variable to know what to do
[15:33] <Keybuk> if it acts on a device or path, it can instance on that
[15:33] <Keybuk> if it writes to the disk, it needs to instance on that path
[15:33] <Keybuk> etc.
[15:34] <Keybuk> unlimited instance jobs inherently can't lock anything, or have any side-effects
[15:34] <Keybuk> and I can't think of anything like that
[15:38] <ion_> Yeah, i can’t think of one either.
[17:00] <Keybuk> sweet
[17:01] <Keybuk> I just worked out something that will now work
[17:01] <Keybuk> assuming that telinit places $RUNLEVEL and $PREVLEVEL in the runlevel event, and sets utmp/wtmp (which is the plan)
[17:01] <Keybuk> /etc/init/jobs.d/rc:
[17:01] <Keybuk>     start on runlevel
[17:01] <Keybuk>     stop on runlevel [!$RUNLEVEL]
[17:02] <Keybuk>
[17:02] <Keybuk>     export RUNLEVEL
[17:02] <Keybuk>
[17:02] <Keybuk>     console owner
[17:02] <Keybuk>     session leader
[17:02] <Keybuk>     exec /etc/init.d/rc $RUNLEVEL
[17:03] <Keybuk> rather than having rc2,3,4,5, etc.
[17:07] <ion_> Nice


[05:16] -queuebot:#ubuntu-release- New binary: openrct2-opensfx [amd64] (mantic-proposed/multiverse) [1.0.3-2] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: openrct2-openmsx [amd64] (mantic-proposed/multiverse) [1.3.1-2] (no packageset)
[06:35] -queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (lunar-proposed) [44.1-0ubuntu1]
[06:55] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (jammy-proposed) [2.765.22]
[06:56] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (jammy-proposed) [2.765.23]
[07:43] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell [source] (lunar-proposed) [44.1-0ubuntu1]
[07:47] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.13-0ubuntu5.4]
[08:23] <ginggs> fossfreedom_: it seems the issue with queuebot announcing daily builds is resolved
[08:43] -queuebot:#ubuntu-release- Packageset: Added libvisual-plugins to i386-whitelist in mantic
[09:44] <LocutusOfBorg> ubuntu-archive, hello, do you plan to do some binNEW processing today?
[09:45] <LocutusOfBorg> I'm just interested in one php package but there is *really* no rush
[09:48] -queuebot:#ubuntu-release- New: accepted edk2 [amd64] (mantic-proposed) [2023.02-2]
[09:48] -queuebot:#ubuntu-release- New: accepted node-monaco-languageclient [amd64] (mantic-proposed) [20230504.93ecd19-1]
[09:48] -queuebot:#ubuntu-release- New: accepted openrct2-openmsx [amd64] (mantic-proposed) [1.3.1-2]
[09:48] -queuebot:#ubuntu-release- New: accepted openrct2-opensfx [amd64] (mantic-proposed) [1.0.3-2]
[09:48] -queuebot:#ubuntu-release- New: accepted pgvector [amd64] (mantic-proposed) [0.4.2-1]
[09:48] -queuebot:#ubuntu-release- New: accepted pgvector [armhf] (mantic-proposed) [0.4.2-1]
[09:48] -queuebot:#ubuntu-release- New: accepted pgvector [riscv64] (mantic-proposed) [0.4.2-1]
[09:48] -queuebot:#ubuntu-release- New: accepted php-league-uri-interfaces [amd64] (mantic-proposed) [2.3.0-1]
[09:48] -queuebot:#ubuntu-release- New: accepted r-cran-memisc [amd64] (mantic-proposed) [<IP_ADDRESS>+dfsg-1]
[09:48] -queuebot:#ubuntu-release- New: accepted r-cran-memisc [armhf] (mantic-proposed) [<IP_ADDRESS>+dfsg-1]
[09:48] -queuebot:#ubuntu-release- New: accepted libjenkins-api-perl [amd64] (mantic-proposed) [0.18-2]
[09:48] -queuebot:#ubuntu-release- New: accepted openrct2-opensfx [amd64] (mantic-proposed) [1.0.3-1]
[09:48] -queuebot:#ubuntu-release- New: accepted pgvector [arm64] (mantic-proposed) [0.4.2-1]
[09:48] -queuebot:#ubuntu-release- New: accepted pgvector [s390x] (mantic-proposed) [0.4.2-1]
[09:48] -queuebot:#ubuntu-release- New: accepted r-cran-memisc [arm64] (mantic-proposed) [<IP_ADDRESS>+dfsg-1]
[09:48] -queuebot:#ubuntu-release- New: accepted r-cran-memisc [riscv64] (mantic-proposed) [<IP_ADDRESS>+dfsg-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-erbium-net [amd64] (mantic-proposed) [1.0.4-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-erbium-net [armhf] (mantic-proposed) [1.0.4-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-erbium-net [riscv64] (mantic-proposed) [1.0.4-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-quoted-printable [arm64] (mantic-proposed) [0.4.8-1]
[09:48] -queuebot:#ubuntu-release- New: accepted openrct2-openmsx [amd64] (mantic-proposed) [1.3.1-1]
[09:48] -queuebot:#ubuntu-release- New: accepted pgvector [ppc64el] (mantic-proposed) [0.4.2-1]
[09:48] -queuebot:#ubuntu-release- New: accepted r-cran-memisc [ppc64el] (mantic-proposed) [<IP_ADDRESS>+dfsg-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-erbium-net [arm64] (mantic-proposed) [1.0.4-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-quoted-printable [amd64] (mantic-proposed) [0.4.8-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-quoted-printable [ppc64el] (mantic-proposed) [0.4.8-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-quoted-printable [s390x] (mantic-proposed) [0.4.8-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-xmltree [arm64] (mantic-proposed) [0.10.3-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-xmltree [ppc64el] (mantic-proposed) [0.10.3-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-xmltree [s390x] (mantic-proposed) [0.10.3-1]
[09:48] -queuebot:#ubuntu-release- New: accepted orsopy [amd64] (mantic-proposed) [1.1.0-1]
[09:48] -queuebot:#ubuntu-release- New: accepted r-cran-memisc [s390x] (mantic-proposed) [<IP_ADDRESS>+dfsg-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-quoted-printable [armhf] (mantic-proposed) [0.4.8-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-xmltree [amd64] (mantic-proposed) [0.10.3-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-xmltree [riscv64] (mantic-proposed) [0.10.3-1]
[09:48] -queuebot:#ubuntu-release- New: accepted php-psr-clock [amd64] (mantic-proposed) [1.0.0-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-quoted-printable [riscv64] (mantic-proposed) [0.4.8-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-erbium-net [ppc64el] (mantic-proposed) [1.0.4-1]
[09:48] -queuebot:#ubuntu-release- New: accepted rust-xmltree [armhf] (mantic-proposed) [0.10.3-1]
[09:49] <LocutusOfBorg> wow thanks!
[11:21] -queuebot:#ubuntu-release- New binary: php-league-uri [amd64] (mantic-proposed/universe) [6.8.0-1] (no packageset)
[12:24] <athos> So, this isc-dhcp nw manager test has been running for 6 days now... I wounder what is going on there (it is indeed running, but REALLY slow)
[12:34] <ginggs> athos: well, it's been queued up for 6 days, but it does not complete and gets restarted
[12:35] <ginggs> according to https://autopkgtest.ubuntu.com/running#pkg-network-manager it has been running for 3.5 hors currently
[12:35] <ginggs> hours, even
[12:36] <ginggs> ubuntu-qa and netplan people are aware of it
[12:57] -queuebot:#ubuntu-release- New: accepted php-league-uri [amd64] (mantic-proposed) [6.8.0-1]
[13:00] -queuebot:#ubuntu-release- Unapproved: sosreport (lunar-proposed/main) [4.5-1ubuntu0 => 4.5.3ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[13:01] -queuebot:#ubuntu-release- Unapproved: sosreport (jammy-proposed/main) [4.4-1ubuntu<IP_ADDRESS> => 4.5.3ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[13:01] -queuebot:#ubuntu-release- Unapproved: sosreport (kinetic-proposed/main) [4.4-1ubuntu<IP_ADDRESS> => 4.5.3ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[13:02] -queuebot:#ubuntu-release- Unapproved: sosreport (bionic-proposed/main) [4.4-1ubuntu<IP_ADDRESS> => 4.5.3ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[13:02] -queuebot:#ubuntu-release- Unapproved: sosreport (focal-proposed/main) [4.4-1ubuntu<IP_ADDRESS> => 4.5.3ubuntu<IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[13:27] -queuebot:#ubuntu-release- Unapproved: rejected yaru-theme [source] (jammy-proposed) [22.04.5]
[13:46] -queuebot:#ubuntu-release- Unapproved: gnutls28 (focal-proposed/main) [3.6.13-2ubuntu1.8 => 3.6.13-2ubuntu1.9] (core, i386-whitelist)
[14:04] -queuebot:#ubuntu-release- New source: nvme-stas (jammy-proposed/primary) [2.2.1-1~ubuntu22.04]
[14:04] -queuebot:#ubuntu-release- New source: nvme-stas (kinetic-proposed/primary) [2.2.1-1~ubuntu22.10]
[14:34] -queuebot:#ubuntu-release- Unapproved: accepted gallery-dl [source] (jammy-backports) [1.25.4-1~bpo22.04.1]
[14:54] <Trevinho> rbasak: hey, what are the changes that are not SRU in yaru?
[14:54] <Trevinho> rbasak: if you mean the upstream changes, those are not code that is going to be used at all... it's just reference.
[15:00] <rbasak> Trevinho: "Upstream reference sources updated to latest versions"
[15:00] <rbasak> and "Sync Gtk3 with upstream"
[15:00] <rbasak> If it's not being used then why are you changing it?
[15:01] <Trevinho> rbasak: it's the upstream code that is used by yaru source code as reference
[15:01] <rbasak> But also, if you have a justification to make, please could you make it in publicly available documentation linked from the changelog?
[15:01] <Trevinho> if you check the meson stuff, you'd see that those files are not touched
[15:04] <rbasak> I don't understand. If it's not necessary, why are you changing it? That just means that we have to have a conversation about it. Can't you just leave it out?
[15:07] <Trevinho> rbasak: so that's a native pacakge, we package what yaru-upstream does and they want to keep track of the upstream code. It could be probably filtered out at packaging time, but that's not something I'd do in a SRU...
[15:08] <Trevinho> So we always did this and it has never been a problem, because it should be clearer how the project is structured
[15:08] <Trevinho> however I'll re-upload explaining the changes.
[15:09] <rbasak> we always did this and it has never been a problem> I appreciate the pain of this, but also, there's no way for me to review this if nobody has documented how it was done before.
[15:10] <Trevinho> rbasak: I understand, I though it was clear... Maybe want a README.source in the debian side?
[15:10] <Trevinho> rbasak: actually there's one already
[15:10] <Trevinho> and it properly states The gnome-shell/upstream directory is just for documentation and to allow three way merges when updating to new versions of gnome-shell, and it is not used for generating the final packages at all"
[15:11] <rbasak> Trevinho: for SRU purposes the right place would be https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases, with approval from an SRU team member. Then future SRU reviewers will be able to confidently follow the instructions there in the knowledge that the instructions themselves have been considered and approved for SRU generally
[15:13] <Trevinho> rbasak: can you maybe draft a special case for that?
[15:17] <athos> Hi ubuntu-release, I believe we need to force/force-hint php-defaults/93ubuntu1 to allow the former php-common (8.1) to break so we can complete the transion :)
[15:18] <rbasak> Trevinho: happy to work on it with you, but I don't understand the justification so I'm not in a position to draft it.
[15:19] <Trevinho> rbasak: well, as said that code is used as reference of what upstream code looks like compared to yaru... It's part of the source package, but it's never used to build the actual theme code that is going to run
[15:24] -queuebot:#ubuntu-release- Unapproved: yaru-theme (jammy-proposed/main) [22.04.4 => 22.04.5] (ubuntu-desktop)
[15:24] <Trevinho> rbasak: re-uploaded with some comments, let me know if that's enough...
[15:26] <rbasak> Trevinho: I'd like a stronger justification for making source-level changes. Without that, IMHO the changes are inappropriate for SRU and should be pulled out.
[15:26] <rbasak> If other SRU team members disagree, then we can discuss it.
[15:27] <Trevinho> rbasak: bah, those are not sources, technically speaking
[15:27] <Trevinho> it's just like a README file...
[15:27] <Trevinho> it's reference data, not source code that ends up being used.
[15:27] <rbasak> It could get used accidentally. Now I have to check.
[15:28] <rbasak> We have a long enough SRU backlog as it is. This just unnecessarily adds to it.
[15:28] <rbasak> Do you understand how this generates extra SRU review work?
[15:29] <Trevinho> rbasak: no, it can't. I mean, it indeed requires checking at what meson does... but it's worth few moments and see that nothing references that. Source is code that is used to build something, those are stale source files.
[15:30] <rbasak> I think you underestimate what it means for a reviewer who doesn't already intimately know the upstream code and the packaging.
[15:32] <Trevinho> rbasak: I understand that, I would have appreciated asking before rejecting, but I also understand it's not easy going through the details all the times.
[15:33] <rbasak> Trevinho: as far as I could tell, the a documented explanation would have required a re-upload. Hence the reject.
[15:34] <rbasak> It's not sufficient for you to persuade me here - whatever the argument was, that needs to have been documented somewhere, and that would have needed a changelog change.
[15:34] <Trevinho> I see, fact is that it was somewhat documented already, but indeed not mentioned-again in the changelog
[15:35] <rbasak> It might be documented what it is in README.source, but it's not documented why it's acceptable even though on the face of it it violates SRU policy. I wouldn't expect to find the latter in README.source.
[15:36] <Trevinho> so I'm happy to have made the change, I just hope is enough... Cause all the tecnical side of backporting fixes and documenting them is quite challenging, and being blocked on things that are not used is not super cool
[15:36] <rbasak> I've been writing some documentation on why I think this is important.
[15:36] <rbasak> To try and help with this.
[15:37] <rbasak> But my position remains the same - it's not sufficient IMHO, sorry. I've asked other SRU team members for an opinion.
[15:38] <Trevinho> fine, it's just hard to find a solution here, given that I could remove all the upstream code, and that's still a source change. While removing the latest change only can be something that upstream developers don't want.
[15:40] <rbasak> You are cherry-picking a bunch of fixes in this upload, no?
[15:40] <rbasak> Why are you making more changes than just those cherry-picks?
[15:40] <Trevinho> rbasak: yes...
[15:41] <Trevinho> BUt, the upstream yaru branch is maintained bu upstream yaru develoepers and they update it with reference code they require
[21:49] -queuebot:#ubuntu-release- Unapproved: gtk4 (lunar-proposed/main) [4.10.1+ds-2ubuntu1 => 4.10.3+ds-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-desktop)
[23:58] -queuebot:#ubuntu-release- New binary: libbiblio-rfid-perl [amd64] (mantic-proposed/none) [0.05-1] (no packageset)
[23:58] -queuebot:#ubuntu-release- New binary: libhash-ordered-perl [amd64] (mantic-proposed/none) [0.014-2] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: rust-bendy [amd64] (mantic-proposed/none) [0.3.3-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: rust-bendy [s390x] (mantic-proposed/none) [0.3.3-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: rust-pep440-rs [ppc64el] (mantic-proposed/none) [0.3.9-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: rust-bendy [ppc64el] (mantic-proposed/none) [0.3.3-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: rust-pep440-rs [amd64] (mantic-proposed/none) [0.3.9-1] (no packageset)
[23:59] -queuebot:#ubuntu-release- New binary: rust-pep440-rs [s390x] (mantic-proposed/none) [0.3.9-1] (no packageset)


[18:12] <sarnold> #ubuntu-desktop needs a new topic please :)
[18:15] <sarnold> as does #ubuntu-devel
[18:24] <housecat> both channels are -t at the request of the developers in there, so they can be fixed by anyone who can copypaste the old topic.
[18:25] <housecat> them being -t is not something i particularly agree with, so im not gonna go do it for them
[18:26] <sarnold> oh cripes. /me paperbag
[18:26] <sarnold> thanks housecat
[18:26] <housecat> no worries


[10:27] <UbuPhillup> Is http://ubuntuonair.com/ down ?
[10:43] <Marlinc> I can't reach it :p
[10:43] <Marlinc> The Ubuntu On Air website should integrate with the Unity Web Apps API :D
[10:45] <UbuPhillup> Marlinc: okey thanks so its not a problem of me ;)
[10:45] <Marlinc> Np :)
[17:36] <crhrabal> ubuntonair.com still seems to be down :(
[17:59] <JoseeAntonioR> crhrabal: yep, we're fixing some stuff and will be up again soon :)
[18:01] <UbuPhillup_> JoseeAntonioR: so is there a Q and A today?
[18:02] <JoseeAntonioR> UbuPhillup_: nope, I think jono forgot to mention but there's no Q&A today :)
[18:02] <JoseeAntonioR> thanks for coming, anyways :)
[18:03] <Marlinc> JoseeAntonioR, you guys should try to add Ubuntu webapps support to the Ubuntu On Air site
[18:03] <UbuPhillup_> JoseeAntonioR: okey thanks ;)
[18:03] <Marlinc> That would be very awesome
[18:03] <Marlinc> Notifications when it goes live and a handy icon in the dash
[18:03] <JoseeAntonioR> Marlinc: good idea, we'll surely have that in mind :)
[18:04] <Marlinc> :)
[18:15] <Marlinc> Hey jono is there's no Q&A today?
[18:15] <crhrabal> yeah jono mentioned it in his last qa
[18:15] <Marlinc> Thats too bad
[18:16] <crhrabal> well he said there "probably" won't be one
[18:16] <Marlinc> :p
[18:16] <crhrabal> which lead me to believe there wouldn't be one
[18:16] <UbuPhillup_> ;(
[18:16] <Marlinc> I didn't watch the entire thing I think
[18:16] <Marlinc> Normally I do
[18:16] <crhrabal> Marlinc: yeah it's at the end
[18:17] <UbuPhillup> crhrabal: where he sad this?
[18:17] <Marlinc> Well okay
[18:18] <crhrabal> ubuphillup: well  i can't really show you since ubuntuonair.com isn't work
[18:18] <crhrabal> working
[18:19] <Marlinc> http://www.youtube.com/watch?v=79mC6KT1q34
[18:20] <Marlinc> Does any of you know if it possible to integrate with the Ubuntu 13.04 sync menu from Python? I asked on Stackoverflow, #ubuntu-app-devel and the app development mailing-list and got no reply at all :(
[18:20] <UbuPhillup> okey
[18:21] <Marlinc> Wut 48 meetings. I hope its going well jono whats quite a lot
[18:23] <jono> Marlinc, it has been a *long* week :-)
[18:23] <Marlinc> Thats*
[18:24] <Marlinc> I would think so
[18:24] <UbuPhillup> Marlinc: ohh yeah I see this video but only until jono plays guitar ;)
[18:24] <Marlinc> I didn't see the last 2-3 minutes either xd
[18:24] <UbuPhillup> ;)
[18:25] <Marlinc> I'm trying out Ubuntu MAAS. I really don't need it but still I'm trying it out
[19:40] <sebsebseb> no session today ?
[19:40] <sebsebseb> no jono today ?
[19:40] <sebsebseb> right seems so
[19:41] <sebsebseb> well I coudn't get on the Ubuntu On Air site anyway
[19:41] <crhrabal> sebsebseb: no session today because jono is in meetings all day
[19:54] <k1l> no jono because everyone watching europe footballs championsleague semifinals :)
[19:56] <sebsebseb> crhrabal: yeah I knew that was coming up when he may not be there
[19:56] <sebsebseb> crhrabal: coudn't remember when though


[06:04] <DalekSec> sakrecoer: Pitti is getting to you guys, just hadn't made it there yet.
[08:49] <sakrecoer> thank you DalekSec :)
[08:51] <DalekSec> Though, isn't US supposed to work with any DE?  Heh.
[09:00] <sakrecoer> DalekSec: its been a hot topic for a while #desktopagnostic :) but it appears we aren't quite there yet.
[09:44] <neo1748> hi
[19:11] <zequence> sakrecoer: krytarik: I'm sure you guys can do the syncing with xubuntu default settings. If it's not done before FF I will try to remember to do it.
[19:38] <zequence> sakrecoer: krytarik: Also, let me know if you need help with the seed thing.
[21:29] <sakrecoer> thanks zequence :) good to know! but i'll di my best so you can relax instead having to do it ;)