[07:59] <oSoMoN> good morning desktoppers, happy Friday!
[07:59] <marcustomlinson> Good morning :)
[08:00] <duflu> Morning oSoMoN, marcustomlinson and seb128?
[08:01] <oSoMoN> hey marcustomlinson, duflu
[08:01] <marcustomlinson> \o
[08:03] <jibel> Hi all
[08:03] <oSoMoN> salut jibel
[08:13] <duflu> Hi jibel
[08:20] <willcooke> morning
[08:21] <oSoMoN> good morning willcooke
[08:22] <duflu> Hi willcooke
[08:26] <willcooke> Happy Friday!
[08:26]  * willcooke checks calendar
[08:26] <willcooke> yes!
[08:39] <seb128> lut oSoMoN
[08:39] <seb128> & jibel
[08:39] <seb128> hey duflu willcooke marcustomlinson
[08:39] <oSoMoN> salut seb128
[08:39] <seb128> happy friday desktopers!
[08:41] <marcustomlinson> Ha! Happy Friday indeed
[08:46] <willcooke> hi seb128 marcustomlinson
[08:47] <marcustomlinson> morning willcooke
[09:02]  * Laney nods
[09:05] <seb128> hey Laney, happy friday!
[09:09] <Laney> hey seb128, happy friday to you :>
[09:14] <oSoMoN> morning Laney
[09:15] <duflu> Morning Laney
[09:25] <seb128> changing location, bbiab
[09:26] <jibel> The issue with spotify happened again. When I launch the snap there is no window decorations, I've to resize the window to make them appear
[09:26] <jibel> I've this message in the logs
[09:26] <jibel> mars 15 10:23:28 sark org.gnome.Shell.desktop[4668]: Window manager warning: Treating resize request of legacy application 0x4200001 as a fullscreen request
[09:35] <seb128> best to open a bug specifying the session( wayland or xorg), the screen resolution you use and maybe a screenshot showing how spotify is placed/looking
[09:35] <seb128> bug on gnome-shell
[09:49] <seb128> andyrock, hey
[09:49] <seb128> andyrock, you need a FFe bug for the indicator, can you open one?
[09:50] <jibel> seb128, I reported bug 1820230 with a test case. Nothing critical but annoying
[09:51] <seb128> jibel, thx, and indeed, that's the sort of annoyance we should try to get rid of
[10:05] <duflu> Oh dear. Too easy for me to confuse ~/git/mutter/clutter/clutter for ~/git/clutter/clutter
[10:05] <duflu> That wasted some time
[10:09] <seb128> :/
[10:10] <seb128> duflu, btw sounds like about time you think about the w.e :)
[10:20] <seb128> jbicha, is there any reason you didn't sync you geary update to disco?
[10:33] <seb128> duflu, I think your comment on bug #1819890 and I can confirm the issue
[10:34] <seb128> if you open e.g gedit on workspace 1, nautilus on 2, evince on 3, go to 3, do 'r' you end up on 3 with evince but with ghost rendering of e.g nautilus
[10:34] <seb128> switching workspaces nautilus is still on 2 as expected and gedit on 1, so it does remember where things are
[10:34] <seb128> and that wipe the 'ghost' apps
[10:35] <seb128> anyway, not an important bug
[10:35] <seb128> but still one
[10:36] <duflu> seb128, OK thanks. I thought it might be a new form of bug 1181666 but maybe not
[10:45] <seb128> willcooke, oh, re your slider comment from yesterday in the sound panel; I didn't check the code but my guess would be that it's expecting
[10:45] <seb128> when you enable the boost you get a legend/mark
[10:45] <seb128> and it's probably another widget/variant and the arrow helps to see on the scale value
[10:50] <willcooke> seb128, ah yeah.  I did wonder if that was the case.  If feels a bit arbitrary to me, but it's not a big deal
[10:50] <willcooke> the transition between the two is pretty cool
[10:50] <seb128> yeah
[10:50] <willcooke> today's pulseaudio oddness:  why isnt spotify making any noises, but I can hear everything else.....
[10:51] <seb128> is the volume for that stream to 0 in settings?
[10:51] <willcooke> just poking around in pavucontrol :)
[10:52] <seb128> poke around the default tools!
[10:52] <willcooke> yeah, seems the stream was muted
[10:52] <willcooke> I wonder why
[10:53] <seb128> does spotify has a sound control? maybe you did it inapp?
[10:53] <willcooke> I'll see if I can recreate it
[10:53] <willcooke> no buggy
[10:53] <willcooke> biggy
[10:53] <willcooke> it *is* buggy
[10:53] <willcooke> :)
[10:59] <seb128> is launchpad/librarian slow for others as well?
[11:00] <acheronuk> yes
[11:00] <seb128> shrug, launchpad :/
[11:12] <acheronuk> can't even download a .dsc (502 Proxy Error)
[11:15] <jbicha> seb128: https://gitlab.gnome.org/GNOME/geary/issues/260 and https://bugs.webkit.org/show_bug.cgi?id=195455
[11:15] <gitbot> GNOME issue 260 in geary "0.13 fails to build on s390x" [1. Crash, Client, Opened]
[11:15] <seb128> jbicha, that's impact .1 but not .0?
[11:15] <jbicha> the webkit issue might be because we switched dh to use cmake+ninja but I haven't had the time to do the rebuilds and re-tests
[11:16] <jbicha> .0 built on ppc64el at the time, .1 had a regression fixed in .2 but then webkit broke ppc64el again
[11:16] <seb128> k, sounds like there is a reason, I just wanted to check it's not an overlook, thx :)
[11:16] <jbicha> either way, we need to do something about s390x or it will still be stuck in disco-proposed
[11:17] <jbicha> I'm kinda hoping xnox would help with geary/s390x since he synced geary 0.13.0-1 :) :)
[11:42] <andyrock> seb128: https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1820259
[11:42] <seb128> andyrock, hey, thx!
[11:52] <seb128> Trevinho, did you see my ping from the other day to include https://code.launchpad.net/~ricotz/libunity/syntax-fixes/+merge/362923 in https://bileto.ubuntu.com/#/ticket/3641 ?
[12:29] <Trevinho> seb128: ah, I saw it... I forgot the tab open somewhere though :(
[12:29] <seb128> Trevinho, no worry :)
[12:32] <xnox> jbicha, heh, well i synced it in because of amd64, cause i thought all my mail issues could be fixed now, but it didn't.
[12:32] <xnox> seb128, jbicha - neither ppc64le nor s390x are web-browser supportable arches. And so far it has been out of scope for me to look into. Nor there was any progress when we asked ibm to help.
[12:53] <seb128> xnox, we should probably just nuke things from those arches then...
[13:34] <willcooke> xnox, btw I pinned your java post on the hub for the next two weeks, so it will always appear at the top (users can dismiss it locally if they wish)
[13:38] <xnox> willcooke, nice.... i still don't have powers to edit the foundations section post.
[13:38] <xnox> willcooke, i like the desktop team updates there, by the way.
[13:38] <willcooke> sec, maybe I can do that
[13:39] <xnox> popey, i wonder why it's discourse.ubuntu.com, and not like the rest of them: community.monzo.com, community.freetrade.io, etc. surely community.ubuntu.com sounds nicer and more human =)
[13:40] <willcooke> xnox, seems I'm a mere moderator, so I cant
[13:40] <willcooke> xnox, it *was* community.u.c but it was decided that it should be changed
[13:41] <willcooke> popey, could you make xnox a moderator of the Foundations category
[13:56] <popey> on it
[14:00] <willcooke> thx popey
[14:01] <seb128> Laney, can you help me with a stupid autopkgtest question
[14:01] <Trevinho> seb128: in the mean time, libunity still fails https://launchpadlibrarian.net/415258488/buildlog_ubuntu-disco-amd64.libunity_7.1.4+19.04.20190315.1-0ubuntu1_BUILDING.txt.gz
[14:02] <seb128> ipset (6.38-1 to 7.1-0ubuntu1)
[14:02] <seb128> autopkgtest for firewalld/0.6.3-4: amd64: Regression ♻
[14:02] <seb128> Laney, how do I tell it to try with the proposed version of firewalld?
[14:02] <seb128> I've a feeling it's a firewall/0.6.3-5ubuntu1 to add with a keyboard to the url
[14:03] <seb128> but I can't never rememner how exactly
[14:03] <popey> xnox: in theory you're now a mod
[14:04]  * seb128 is reading https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Bug_reporting
[14:04] <seb128> I could do all-proposed but that's not really what I want
[14:29] <Laney> seb128: locally?
[14:29] <seb128> Laney, no, archive
[14:29] <Laney> ok, then https://wiki.ubuntu.com/ProposedMigration#How_to_re-run_autopkgtests_with_dependencies_on_other_packages_in_the_proposed_pocket
[14:30] <seb128> thx, I was onthe wikipage :/
[14:30] <seb128> I knew it was somewhere
[14:31] <seb128> bah, wrong tab closing :p
[14:32] <willcooke> :)
[14:32] <seb128> let's see how that goes
[16:37] <seb128> Laney, unsure if that's an easy one or something you would prefer someone non desktop to review, https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1820259 ?
[16:37] <seb128> it should be a no-op for disco
[16:37] <seb128> but we need it to start the bionic SRU process
[16:43] <Laney> is it urgent?
[16:43] <Laney> I have it in the email queue but wasn't going to look at those right away
[16:46] <seb128> Laney, I guess not, I wanted to review/merge that today to have it off my list but next week is ok
[16:46] <seb128> it's more my personal mental problem to want to clear my todo before the w.e :p
[16:47] <seb128> bah, I'm down an hole with firewalld
[16:47] <seb128> so the remaining issue is an iptables one
[16:47] <seb128> which is fixed upstream but require changes from libnftnl
[16:47] <seb128> which aren't in any release
[16:48] <seb128> I don't feel like I understand iptables enough to start backporting unreleased new features
[16:48] <seb128> I'm going to dump what I know in a bug
[16:48] <seb128> Laney, wdty about skipping the firewalld failure? the other issues are resolved
[16:49] <seb128> I should probalby mention that on -devel
[17:02] <seb128> Laney, details on #ubuntu-devel, it's not especially for you though I would still welcome your opinion on skipping the firewalld results to unblock pygobject/nm/gtk
[17:02] <Laney> it'd probably make sense, let me finish this fix then I can be at your service :>
[17:05] <seb128> thx
[17:05] <seb128> ignore the ffe for today
[17:05] <seb128> next week is fine
[17:22] <oSoMoN> I'm calling it a day, have a great week-end everyone!
[17:41] <Laney> there we go
[17:41] <Laney> now you can see GNOME on Xorg again /o\
[17:49] <willcooke> night all
[17:49] <willcooke> happy weekend
[17:56] <seb128> back, sorry dropped offline for a bit I think
[18:13] <seb128> have a good w.e desktopers
[20:11] <seb128> Trevinho, ricotz, hum, I don't understand the new commit thing on https://bileto.ubuntu.com/#/ticket/3641
[20:11] <seb128> but the ppa build failed
[20:12] <seb128> protocol-scope-interface.vala:134.7-134.46: error: Synchronous out-parameters are not supported in async methods
[20:12] <seb128>       out HashTable<string, Variant> out_hints,
[20:12] <seb128> ricotz, seems that's not addressed in https://code.launchpad.net/~ricotz/libunity/syntax-fixes/+merge/362923 ?
[20:24] <ricotz> seb128, hmm, the fix for this error is literally the first hunk of the merge
[20:25] <seb128> ok, so maybe that has to do with the missing commit thing
[20:25] <seb128> which I don't understand
[20:25] <ricotz> there are two commit in this merge
[20:25] <seb128> well the mp was added today
[20:25] <seb128> which is a commit not considered?
[20:25] <ricotz> see "Unmerged revisions"
[20:27] <seb128> but why did it not merge those?
[20:27] <ricotz> how would I know the answer to that ;)
[20:28] <seb128> I was asking in case
[20:28] <seb128> Trevinho might know
[20:28] <seb128> maybe it has to do with the revisions approved in the mp
[20:31] <ricotz> no idea what is happening behind the scenes there
[20:33] <ricotz> the package changelog says "disco/libunity: Failed to merge https://code.launchpad.net/~ricotz/libunity/syntax-fixes"
[20:35] <seb128> ricotz, k, I've a guess that it's because the mp was not approved, I did that now and retried a build
[20:35] <seb128> ricotz, thx for responding, sorry for pinging you about infra things
[20:38] <ricotz> np, I am hoping this eventually works out
[20:58] <seb128> ricotz, Trevinho, k, it failed again but the new log is more useful, the first mp failed to commit due to a lack of commit message in the mp (I'm pretty sure that used to error out with a clear message on the web service side?), I added one and retry
[20:58] <seb128> ricotz, can you write a commit message that makes sense for a package upload for yours? it's used for the changelog
[20:59] <seb128> I changed it because 'This is WIP and should be picked up by someone knowing more about reverse-dependencies.' is not something that gives confidence in an upload
[21:48] <tjaalton> should the gtk scrollbar be fully visible on disco?
[21:51] <tjaalton> nevermind


[01:30] <DanaG> Bummer.  Are there any Marvell ARM thingies that WILL run lucid?
[01:31] <DanaG> I'm still wanting an ARM with PCIe slot. =þ
[01:36] <Martyn> DanaG : Dove
[01:36] <Martyn> and an ARM with a PCIe slot -- is a tegra2
[01:36] <Martyn> two PCIe 1x slots in fact
[01:36] <Martyn> (Mini PCIe)
[01:36] <DanaG> Hmm, but that already has a video card... a non-open one.
[01:37] <DanaG> Interesting adapter: http://www.hwtools.net/Adapter/PE4L.html
[01:37] <persia> Doesn't mean you have to use it.
[01:37] <Martyn> well, pcie doesn't have a lot of bandwidth, when you're using just one lane
[01:38] <Martyn> DanaG : But even if it's not open, that doesn't mean there aren't open source DRIVERS for it
[01:38] <Martyn> 2D is well supported
[01:38] <persia> WIth nouveau?
[01:38] <Martyn> why would nouveau even work?
[01:38] <Martyn> the technology in use on the tegra2 has nothing in common with the nvidia GPU's
[01:39] <Martyn> it's made by nVidia..
[01:39] <Martyn> that's about it
[01:39] <persia> Ah :)
[01:39] <Martyn> 2D is supported by it being a bog-standard framebuffer
[01:39] <persia> Which drivers then?
[01:39] <Martyn> fbcon
[01:39] <persia> Oh.  That make sense.
[01:39] <Martyn> persia : And I even disabled /that/
[01:39] <Martyn> since it steals memory that I want for appliations
[01:39] <persia> heh.
[01:40] <Martyn> servers don't need memory, so instead of having nearly a gig, I had barely more than 600meg
[01:40] <Martyn> servers don't need VIDEO rather
[01:40] <persia> Right.
[01:40] <persia> I'm down 512MB on one of my servers for similar reasons, and thinking about fixing it (although with 4G, it's a little less painful)
[01:42] <DanaG> hmm, I can't find much about Marvell Dove.  No boards easily findable.
[01:42] <Martyn> They aren't easy to get, no.
[01:42] <Martyn> DanaG : Frankly, if you're patient, there is a new OMAP44xx board coming out soon
[01:42] <Martyn> and that is a DUAL CORE cortex a9
[01:42] <Martyn> more than powerful enough
[01:42] <Martyn> or you can spend $300 and get into the tegra2 program
[01:42] <DanaG> I'm not in any rush to buy anything... I'm just eyeing stuff and thinking "ooh, that looks interesting." =þ
[01:43] <Martyn> well, closer to $400
[01:43] <Martyn> it's a great board though, and we have ubuntu working now
[01:43] <DanaG> Hmm, is there info about that board, publicly available?
[01:45] <DanaG> heh, I can't find even a _picture_ of the Marvell Dove boards.
[01:46] <DanaG> http://swik.net/Gentoo/Planet+Gentoo/Ra%C3%BAl+Porcel:+ARMv7+SoCs:+Freescale+i.MX51+Babbage,+TI+OMAP3,+Marvell+Dove%2FArmada,+Qualcomm+Snapdragon%E2%80%A6/do9pt
[01:46] <DanaG> ah
[01:48] <DanaG> I see... it's all very new stuff.
[01:50] <Martyn> DanaG : There's even a public FORUM for development of tegra2
[01:50] <Martyn> http://developer.nvidia.com/tegra/forum
[01:51] <Martyn> I am prevented from photographing it due to NDA, but it's neat
[01:52] <DanaG> Can you say if it's a mobile form, or a desktop-ish form?
[01:52] <DanaG> Desktop-is as in, openrd-base counts as that.
[01:53] <Martyn> mobile, about 15cm on a side, square
[01:53] <Martyn> embedded memory, two PCIe slots, three USB, one USB OTG (used to load firmware), etc..
[01:53] <DanaG> Spiffy.
[01:53] <DanaG> Hmm, is there an expiration date on that NDA?  Or is the date itself... under NDA?
[02:28] <persia> Martyn: Are you allowed to describe the embedded memory?  raw NOR, raw NAND, uses FTL, etc.?
[02:29] <persia> (and how much?)
[02:33] <Martyn> persia : There is 1GB of 667MHz DDR2 ram
[02:33] <Martyn> I honestly don't know how much flash there is, but there is quite a bit
[02:33] <Martyn> there is no NOR that I'm aware of, but I have a SPI nor chip attached (8mbit) for my own use
[02:34] <Martyn> I know they also have some kind of SPI EEPROM
[02:35] <persia> Thanks.  I'm mostly interested in flash, as I like the idea of / on NAND, but that can wait for retail :)
[02:36]  * persia is mostly happy to wait for retail, but kinda wishes things would move a little faster sometimes
[02:36] <Martyn> http://developer.nvidia.com/tegra/tegra-devkit-features
[02:36] <Martyn> They released a devkit picture and overview!
[02:36] <Martyn> No more NDA for me then
[02:36] <Martyn> 512MB SLC nand
[02:37] <persia> Nifty!
[02:37] <Martyn> it's a droolable board, and they are just now out of stock too
[02:37] <Martyn> more stock coming around May 1
[02:37] <persia> Oh :(  512MB isn't quite enough.
[02:37] <Martyn> It's PLENTY for a boot/root filesystem
[02:37] <Martyn> you can put /usr on something else
[02:37] <persia> Yeah.
[02:37] <Martyn> persia : Consider for a moment, that ALL of android fits in 64MB
[02:38] <Martyn> 128MB on th eoutside
[02:38] <persia> My preference is / on NAND, and /var, /home on rotary (as I churn that), but that's just me.
[02:38] <persia> I only consider Ubuntu, which wants ~2GB for the base install.
[02:38] <Martyn> doens't need to be
[02:38] <Martyn> I've gotten the base down to 384M
[02:38] <persia> Depends on the install.  servers can be a lot less.
[02:39] <Martyn> base is -very small-
[02:39] <Martyn> everything else on top of it is big
[02:39] <persia> Right.
[02:39] <Martyn> but my tarball of base is 276mb right now
[02:39] <Martyn> uncompressed
[02:40] <persia> My armel buildd chroot is 304MB uncompressed.
[02:40] <Martyn> that's about right
[02:40] <Martyn> and if you do tasksel server, it increases to ~380
[02:40] <persia> (base+build-essential+vim-tiny+less)
[02:40] <Martyn> yeah, you need GCC in there
[02:40] <persia> For my buildd?  Yeah :)
[02:41] <persia> But it gets *lots* bigger when you install all the Desktop/Netbook stuff.
[02:41] <Martyn> depends what you install
[02:42] <Martyn> I have basic browser, and support files, coming in at ~780m
[02:42] <persia> Oh, did you ever get a chance to dig into eucalyptus-nc and make it work for headless managed servers, rather than just KVM?
[02:42] <Martyn> no
[02:42] <Martyn> that's our new blueprint for UDS-M
[02:42] <Martyn> one of three that we've decided on
[02:42] <persia> Oh, cool.
[02:42] <persia> What are the other two?
[02:42] <Martyn> eucalyptus + LXC is one
[02:42] <Martyn> arm-server image without kernel/initrd
[02:43] <Martyn> so that more people can just download the .img and get working
[02:43] <Martyn> (because other than kernel/initrd .. all armv7 images are the same)
[02:43] <persia> I'm philosophically opposed to that, because I think separating the kernel from the rest of it is poor design, but yeah, that's probably best until we can *fix* the issues with ARM kernels.
[02:43] <Martyn> yep.
[02:44] <persia> Actually, do you have a working qemu target for your board?
[02:44] <Martyn> but the kernel --is-- separate .. there's no reason you shouldn't be able to get a .img of an ext4 filesystem
[02:44] <Martyn> no.  We are not going to do QEMU of our board
[02:44] <Martyn> we're not in the business of building simulators
[02:44] <Martyn> by not doing so, we'll get to hardware that much faster
[02:44] <persia> Fair.
[02:45] <persia> Means no chance of changing the qemu kernel target though :)
[02:45] <Martyn> plus the performance of qemu of multicore architectures -sucks-
[02:45] <Martyn> much less of quad core
[02:45] <persia> Yeah :)
[02:45] <Martyn> much less one with 4GB of ram
[02:45] <persia> But I argume the kernel isn't separate: it inherently depends on the toolchain, and is interrelated.
[02:46] <persia> The initrd is even more not separate, since it's constructed based on the filesystem.
[02:46] <persia> And the filesystem contains all the kernel modules, etc.
[02:46] <Martyn> but the initrd is mostly -not used- by ARM targets
[02:46] <persia> But that's all well-known, and it doesn't make the situation better for folks stuck in the embedded model.
[02:46] <Martyn> in fact, Dustin and I use monolithic kernels
[02:47] <Martyn> right
[02:47] <Martyn> so, if you ignore it (and you can .. ) things get easier
[02:47] <Martyn> plus you can build the initrd after completing the install with a monolithic kernel if needed
[02:47] <persia> Well, I won't ignore it, but I'm willing to take a longer term view, and let folks work around it for now :)
[02:48] <persia> For some classes of install: the d-i installer is based inside the initrd, for example :)
[02:48] <persia> Which installer is the one used by the server installs.
[02:48] <persia> But I'll attend the session: some of this can be worked around.
[02:48] <persia> And what can't can probably be scripted in some way.
[02:49] <persia> So, what's the third spec?
[02:54] <Martyn> that's private for now
[02:54] <Martyn> but just for a week or so while the guy working on it gets it completed
[02:55] <Martyn> it's something around cluster control
[02:55] <Martyn> (aka cloud control)
[02:55] <persia> OK.  From your first comment I worried that you'd forgotten that UDS is incredibly public (sessions are icecasted, specs are on the internet, etc.)
[02:56] <Martyn> No, I just don't want to say what I don't know :)
[02:56] <persia> That's as much detail as I sought.  Makes sense, given the vision from your webpages.
[04:03]  * DanaG sticks with ubuntu.  Angstrom is a pain.  Ubuntu on my beagle matches my host system's development environment perfectly. =þ
[04:05] <DanaG> hmm, is the GPU on that a PCI device, or a "platform" device (a.k.a. not PCI)?
[04:06] <DanaG> And can it run compiz? =þ
[04:07] <DanaG> hmm, which of the two slots is "external" MMC/SD?
[04:09] <persia> It's times like this that one wishes vendor spec sheets came with dmesg output and lspci -vvn and lsusb -v :)
[04:10] <DanaG> yeah.  I'd hardly call that too much to ask.
[04:23] <persia> I think we need generic booting kernels first.
[04:23] <persia> Most of the other architectures have them, so now we just look silly.
[04:24] <persia> Mind you, powerpc seems to be moving in the multi-kernel direction, but I hope that's just a short-term thing.
[04:47] <DanaG>  error: expected type-specifier before ‘boost’
[04:47] <DanaG> ARGH
[04:48] <DanaG> er, wrong tab... off-topic for this channel.
[09:33] <ericm> who can point me a cross compiling friendly debian package as an example?
[09:34] <lool> ericm: You mean to cross debuild it?
[09:34] <lool> ericm: You could try the x-loader or u-boot packages in lucid, I fixed them to be cross-buildable
[09:35] <ericm> lool, thanks - I'll take a look
[09:37] <ericm> lool, are they tracked with bzr?
[09:37] <lool> ericm: All packages are nowadays  :)
[09:37] <lool> well almost all
[09:38] <lool> ericm: try bzr branch lp:ubuntu/x-loader
[09:38] <ericm> https://launchpad.net/ubuntu/lucid/+source/x-loader, I'm seeing it might be managed with git?
[09:38] <lool> ericm: the git you see there is in the version because it's coming from git upstream
[09:38] <lool> So the version mentions this is a git snapshot
[09:39] <ericm> lool, ok - so it's actually managed by git and synced on lp with bzr?
[09:40] <lool> ericm: The way to retrieve exactly what's in the archive locally is "apt-get source", when you actually want to commit to the *packaging* vcs of some package, you can check whether the package has Vcs-* headers, or simply use "debcheckout" which will checkout the relevant Vcs (or just apt-get source if no Vcs was found)
[09:40] <lool> ericm: *Upstream* uses git
[09:40] <ericm> lool, ah I see
[09:40] <lool> ericm: For instance, I uploaded a snapshot of valgrind 3.6.0 from SVN and used:  Version: 1:3.6.0~svn20100212-0ubuntu4
[09:41] <lool> Just to reflect that I took the snapshot on 20100212
[09:41] <ericm> lool, so the bzr only tracks the snapshots, not exactly sync'ed with upstream in full history?
[09:42] <lool> ericm: We have automated imports of what reaches the archive into bzr
[09:42] <lool> ericm: So the history is only that of the Ubuntu uploads
[09:42] <ericm> lool, btw - it looks to me x-loader/debian/rules is strange, no binary target?
[09:42] <lool> ericm: we have another import for the debian upload, and these are done in a compatible way so that you can merge between them
[09:42] <ericm> and dh_auto_build seems to do the magic of cross compiling?
[09:43] <lool> ericm: However if we were to track upstream history (which we do relatively rarely), we'd have to setup a git import in Launchpad first
[09:43] <lool> ericm: That's the new style "dh" rules, it basically say "do the standard thing unless I write an override"
[09:44] <lool> ericm: You could try cross-building zlib
[09:45] <lool> it's more standard-style
[09:45] <ericm> lool, ok let me take a look
[09:49] <hrw> hi
[09:49] <lool> hi
[09:49] <ericm> lool, well it looks like zlib doesn't specify --host in its configure, just with a CC assignment before ./configure, which will work in most cases?
[09:49] <lool> ericm: zlib is not using autoconf IIRC
[09:50] <lool> ericm: So its configure doesn't support --host and --build
[09:50] <lool> ericm: Yes, the package should cross-build, I cross-built it recently
[09:50] <ericm> and CC="$(DEB_HOST_GNU_TYPE)-gcc" doesn't work with codesourcery toolchain and others
[09:50] <lool> ericm: To cross-build it, try something like DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -B -us -uc -aarmel -d
[09:51] <ericm> might need some way to specify the toolchain if it's not using the standard gcc naming convention
[09:51] <lool> ericm: Yes, that's the first problem you'll encounter
[09:51] <lool> ericm: then your package will also fail to build near dh_shlibdeps because codesourcery doesn't include debian specific shlibs information
[09:51] <ericm> lool, :-(
[09:51] <lool> ericm: I'm afraid it's not possible to switch triplet, many many upstreams expect $triplet-gcc
[09:52] <hrw> lool: OE has patch to make zlib more autotools
[09:52] <lool> ericm: What you need is debian/ubuntu cross-building training  :-)
[09:52] <lool> hrw: Wont help dh_shlibdeps I'm afraid
[09:52] <ericm> lool, yes - any references?
[09:52] <ericm> lool, I'm a slack
[09:52] <lool> ericm: Let me email you the slides
[09:52] <ericm> lool, that will be nice
[09:52] <hrw> we remove configure, makefile.in and place configure.ac + makefile.am + zlib.pc.in
[09:52] <hrw> lool: probably not
[09:52] <lool> ericm: You're not going into safe and nicely working territory, this is pushing the limits of our current systems a bit  :-)
[09:52] <nosse1> lool: Would it be possible to gain a copy of those slides?
[09:53] <nosse1> lool: We are working with the same issues here.
[09:53] <lool> ericm: sent
[09:53] <ericm> lool, thanks
[09:54] <lool> nosse1: It would, but I'd have to strip them slightly and double-check internally
[09:54] <nosse1> lool: Please do. I'd be grateful.
[09:54] <lool> nosse1: Sorry, what's your real name again?
[09:55] <lool> nosse1: will check
[09:55] <nosse1> lool: My name is Svein Seldal
[09:56] <lool> nosse1: People who I need to check with are sleeping still; I'll check later today, if I forget, please remind me
[09:56] <ogra> lool, time for an #ubuntu-classroom session ;)
[09:56] <nosse1> lool: FYI I've finally installed Lucid on AM3517 eval kit from TI. And I'm using the CS toolchain to cross the kernel, qt and our application while running "mainstream" ubuntu on the rest
[09:56] <lool> ericm: I'm afraid you'll miss the '[ DEMO ]' parts  :)
[09:56] <lool> ericm: xbuild.txt has notes on what I'd actually be typing there
[09:57] <lool> nosse1: Nice
[09:57] <ericm> lool, I went roughly through the first several slides, and decided to native build in my chroot :-)
[09:57] <lool> ericm: lol
[09:57] <lool> ericm: I think you're doing the right thing
[09:58] <lool> ericm: For people with very slow hardware, or generally resource-constrained hardware or no hardware I'd advocate trying qemu-user
[09:58] <lool> I think I should fix our cross-build tool to not care about build-dep loops when converting pre-built packages from the archive
[09:59] <ericm> lool, indeed
[09:59] <nosse1> Since it is possible to mix host and target binaries in a chroot environment I played with the idea to inject the CS cross compiler into the chroot env to use host native tools for building.
[09:59] <lool> If I were to fix it, we'd have a single tool one step way of cross-building any package which can be cross-built *if* you have a dpkg-cross compatible toolchain
[09:59] <nosse1> I don't know if it's even possible or if it's just an crazy idea... :o
[10:00] <lool> nosse1: It's definitely possible, I cover this in my slides, well I mention the idea
[10:00] <lool> nosse1: it's possible in three ways
[10:00] <lool> nosse1: a) real hardware + icecc to move the actual compilation from your slow hardware to a remote intel host running a cross toolchain
[10:01] <lool> b) QEMU machine emulation (emulating hardware), just like a)
[10:01] <nosse1> Point is target native compilation, qemu/chroot is all very slow. That is the one reason you would want to use the CS cross compiler
[10:01] <lool> c) qemu-user emulation or sb/sb2 like emulation and actual intel binaries in your chroot; "croco" which suihkulokki maintains upstream on gitorious does this
[10:02] <lool> nosse1: the compilation isn't the only slow point though
[10:02] <lool> that's typically the case for large C++ apps like Qt, but there are other issues
[10:03] <nosse1> lool: You asked about my name. Here's my lauchpad profile: https://launchpad.net/~sveinse
[10:04] <ogra> wow, the netbook installer looks really nice
[10:05] <lool> nosse1: Yup found it googling your name
[10:05] <persia> lool: Are you planning to drop clean croco support into maverick?
[10:05] <lool> persia: drop?  you mean provide/upload?
[10:06] <persia> Yes.
[10:06] <ogra> drop into :)
[10:06] <lool> persia: I'd love to
[10:06] <nosse1> lool: I need to go to a meeting. I'll remind you later if doesnt hear anything ;)  Thanks!
[10:06] <persia> Lovely.  Will this be something that has to be installed on both the chroot and the host, or just the chroot?
[10:07] <lool> persia: Just the chroot
[10:07] <lool> persia: it's qemu-user style emulation
[10:09] <persia> So how does it get to the non-chroot binaries, or does one have to install both architectures in the chroot?
[10:09] <lool> persia: exactly
[10:09] <persia> Oh :)
[10:10] <lool> There are various approaches to this kind of hack; in croco, you have a croco.map file which is used when intercepting exec() calls
[10:10] <persia> I don't suppose there's some way we could adjust the binfmt-misc wrapper to catch some stuff and execute that natively without adding to the chroot, is there?
[10:10] <lool> not really
[10:11] <lool> I mean, the kernel/binfmt will do the right thing and run the proper binaries
[10:11] <lool> That is, it will see that's for intel and just run them without qemu-arm-static
[10:11] <lool> or see it's for arm and run them with it
[10:11] <persia> RIght.  I was kinda hoping for a way to get croco acceleration out of a Souyz chroot, but I don't think that's feasible.
[10:11] <lool> What the kernel doesn't do is remap what you really want to run depending on the path
[10:11] <persia> Needs a special crocoised chroot.
[10:12] <lool> I personally think security tools might be a better fit for this, but I'm not technical enough to look into it yet
[10:12] <lool> persia: Well you typically want your apps to run chroot-ed as to limit their view on files to the ones you have in your build env
[10:13] <lool> If they run chrooted, then you need chrooted binaries and their libraries; you could run them from the outside and then chroot, but many of them fork() to run other apps
[10:13] <lool> such as gcc calling cc1 or so
[10:13] <persia> Oh, certainly.  I just wanted to reuse the same chroots for native and non-native.
[10:13] <persia> But I don't think that this will work with croco.
[10:13] <lool> persia: That works
[10:13] <ogra> binfmt should catch that
[10:14] <ogra> but you will effectively end up with two full environments in one
[10:14] <lool> persia: When you enter the chroot with croco turned on, it intercepts calls to e.g. /usr/bin/gcc, but if you enter it normally, it doesn't
[10:14] <lool> ogra: Not related to binfmt really
[10:15] <persia> ogra: Indeed, and it works well, so I can just `pull-soyuz-chroot lucid armel; sbuild -d lucid-armel-soyuz foo.dsc`, but that's not as fast as it could be.
[10:16] <persia> lool: Right, but the chroot needs to be multi-arch for croco to work, which the soyuz chroots aren't (and shouldn't be).
[10:16] <lool> persia: What do you mean multi-arch?
[10:16] <persia> having e.g. i386 *AND* armel binaries.
[10:16] <lool> persia: What I mean is that once you've included croco in your chroot (currently in /croco) you can still use it as before
[10:16] <persia> Right.
[10:17] <persia> So we can have a script that adds croco to a chroot, but we can't expect to install something on the host that automatically does croco-acceleration for all chroots.
[10:22] <lool> persia: Well unless you make it part of your build tool, e.g. mount --bind /host/croco /build-chroot/croco
[10:23] <persia> And all the native stuff would live under /croco ?
[10:23] <lool> Yes
[10:24] <persia> Oh, suddenly that looks a lot nicer.
[10:31] <persia> Right.  I think I have an idea how to do that, at least for schroots.  pbuilder will require more investigation.
[10:31] <persia> (or rather pbuilder-dist integration: pbuilder has hooks that make it easy for folks that know how to use pbuilder)
[10:34] <ogra> #define DEFAULT_DEVICE "/dev/fb"
[10:34] <ogra>  /* FIXME: We don't really want to do it like this... */
[10:34]  * ogra grumbles about the omapfb xserver
[10:35] <ogra> they could at least have picked fb0
[10:36] <persia> So, XorA suggested we could (temporarily) ship a udev rule in the xserver package that would add the symlink.
[10:36] <persia> XorA also suggested that he expected to be directed to fix it in the near future.
[10:37] <ogra> well, given that we're in hard freeze it wont happen for lucid anyway
[10:37] <ogra> and for maverick we should just fix it properly
[10:50] <lool> Can't we fix this omap specific package instead?
[10:51] <lool> How does Debian do it?
[10:51] <ogra> lool, thast what i was saying :)
[10:52] <ogra> fix it properly by adding a routine that detects the device instead of hardcoding it
[10:52] <lool> ogra: switching to fb0 would be good enough for lucid
[10:52] <ogra> sure
[10:53] <persia> It's not terribly difficult to fix, but if XorA plans to fix it, I'm not sure of the value of trying to fix it before him.
[10:53] <lool> persia: Having the package in lucid work?  :)
[10:54] <persia> That's trivially done by shipping a udev rule to create the node the software wants.
[10:54]  * ogra checks the other omapfb package as well ... i bet it uses the same hack
[10:54] <persia> Could add a s/fb/fb0/ patch, but I had the impression from the discussion this weekend there was some reason this was complex.
[10:55] <lool> .BI "Option \*qfbdev\*q \*q" string \*q
[10:55] <lool> The framebuffer device to use. Default: /dev/fb0.
[10:55] <lool> From man/fbdev.man
[10:57] <lool> apparently this is a xorg default for options named "fbdev" -- couldn't find any actual default in xorg-fbdev
[10:57] <ogra> persia, given that we only support one board atm and in the light that fb0 is usually the default i think its safe to just take fb0
[10:57] <ogra> for maverick we should add some detection code though
[10:58] <persia> XorA|gone: When you get back, please explain why this is a good/not good idea in some detail.
[10:58] <lool> fbdevHWInit(pScrn,NULL,xf86FindOptionValue(fPtr->pEnt->device->options,"fbdev"))
[10:58] <persia> ogra: My fear is that the hardcoding is more complex and deeper than you think.
[10:58] <ogra> persia, not really
[10:59] <ogra> but i'll test it as soon as this netbook install is done
[10:59] <ogra> (if that finishes before the volcano stops spitting ash :P )
[10:59] <persia> OK.  All I can advise is to check the weekend backscroll.  If it trivially works, go ahead.  If it doesn't, let's work around it for lucid.
[11:01] <lool> persia, ogra: So apparently, xorg-server/hw/xfree86/fbdevhw/fbdevhw.c does the default on fb0
[11:01] <lool> It can be overriden with FRAMEBUFFER in the env
[11:02] <lool> or in the config obviously
[11:02] <ogra> yeah
[11:02] <ogra> so omapfb should just do the same
[11:02] <persia> lool: Indeed.  THis is an omapfb-specific bug.
[11:02] <persia> (and known to be a bug)
[11:03] <lool> fbdevHWInit() calls fbdev_open() which open()s the fbdev, and that's pretty much it; I think src/omapfb-driver.c could do the same
[11:03] <lool> Uh plus it checks for fd > 0 ohw ugly
[11:05] <persia> There's some trickiness in omapfb because it makes assumptions that certain fbX devices have certain special features/functions.
[11:06] <persia> And this needs massive cleanup (upstream), which is why I believe the lucid-timeframe answer is a udev rule.
[11:06] <ogra> these are in different source files
[11:06] <ogra> xv has its separate source and uses fb1
[11:07] <ogra> root@babbage2:/xf86-video-omapfb-0.1.1# grep -r /dev/fb *
[11:07] <ogra> src/omapfb-driver.c:#define DEFAULT_DEVICE "/dev/fb"
[11:07] <ogra> src/omapfb-xv.c:#define OMAP_FBDEV1_NAME "/dev/fb1"
[11:07] <ogra> in that light src/omapfb-driver.c should just be hardcoded to fb0
[11:07] <cooloney> plars and GrueMaster, could you please guys to help look at bug #567157
[11:07] <ogra> unless lool wants to add the proper fbdev_open() calls :)
[11:07] <ubot4> Launchpad bug 567157 in linux-fsl-imx51 (Ubuntu) "regulators enabled at boot and also print error messages at boot. (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/567157
[11:08] <lool> ogra: I'll do it in my CFT
[11:08] <ogra> CFT ?
[11:08]  * ogra wonders what C means
[11:08] <lool> copious free time
[11:08] <ogra> ah
[11:08] <eggonlea> hi, anybody knows about netbook-launcher-efl? Would the XV window get damage info again after it redraws application GUI (e.g. totem)? Now it seems destroys the colorkey background so video cannot be shown correctly.
[11:10] <ogra> bah, crap flash-kernel fails in ubiquity
[11:17] <lool> eggonlea: Sorry no idea
[11:17] <lool> Who's maintaining netbook-launcher-efl here?
[11:17] <lool> JamieBennett: is that you?
[11:18] <JamieBennett> lool: mterry
[11:19] <persia> Isn't mterry upstream?
[11:19] <JamieBennett> persia: he is now but not the original upstream
[11:19] <lool> eggonlea: Try pinging mterry on #ubuntu-devel or so, he's upstream and is easter time
[11:19] <lool> *eastern
[11:19] <JamieBennett> he is looking after n-l-efl
[11:20] <eggonlea> lool: great, thanks!
[11:21] <persia> Yeah, well, teams have member turnover, but an upstream contact is an upstream contact :)
[11:21] <JamieBennett> persia: :)
[12:55] <nosse1> lool: I hope I wasn't rude or anything about requesting the presentation earlier on. I was kind of in a hurry, so I threw myself into the discussion
[13:01] <lool> nosse1: Oh not at all
[13:01] <lool> nosse1: I wouldn't have mentionned it here if there was no chance of publishing it
[13:08]  * sveinse got his beloved old nick back. *nosse1* is now known as *sveinse*
[13:13] <sveinse> Is #ubuntu-arm logged anywhere?
[13:14] <rcn-ee> sveinse, http://irclogs.ubuntu.com/ but usually an hour behind.. ;)
[13:14] <ogra> irclogs.ubuntu.com
[13:14] <sveinse> rcn-ee: np, I'm looking for something weeks old
[13:15] <rcn-ee> ogra, so i was playing around with different methods...  The NetInstall really doesn't like it when i force nand to read only.. ;)
[13:15] <ogra> indeed
[13:16] <ogra> file a bug on flash-kernel so we can cancel the installation properly with a clean error message
[13:17] <rcn-ee> i will, after some more testing..  its weird since early in the flash-kernel script it calls the one /etc/flash*.conf so it shoudl exit. (well it works on an already built image) but the NetInstall still runs it..
[13:18] <ogra> while its sourced, the omap code doesnt use anything from it
[13:18] <ogra> actually we only introduced it for imx51 since that has an awful setup
[13:18] <rcn-ee> yeah i saw that, awful bootloader mess you had to work thru...
[13:19] <ogra> after using it for three releases i really like redboot more than uboot
[13:19] <ogra> :)
[13:19] <hrw> ogra: can you tell more about that 'awful setup'?
[13:19] <rcn-ee> the easy thing, would be a variable in that config to please leave the nand alone
[13:19] <ogra> hrw, abusing your install media as "bootfloppy"
[13:20] <hrw> ah
[13:20] <ogra> truncating it at the end of the install ...
[13:20] <ogra> the babbage board can only boot from SD
[13:20] <ogra> but you cant easily install to the installation media you run from
[13:21] <ogra> so babbage requires you to install to USB and to keep the SD you installed from as boot media, carrying a special non-data partition that holds redboot, kernel, initramfs and the redboot config (simulating a flash)
[13:32] <hrw> ough
[13:34] <persia> sveinse: Did you find what you needed in the logs?  They are (up to) an hour out of date, but they should go back to within a couple weeks of when I opened the channel.
[13:37] <sveinse> persia: yes, thank you
[13:45] <sveinse> Anyone here with openocd and kernel debug experience?
[13:46] <hrw> I use openocd only to reboot sheevaplug
[13:47] <NCommander> ogra: when you use a non-hacked up u-boot, your opinion will likely change
[13:47] <ogra> NCommander, nope
[13:47] <ogra> i like fast boots ...
[13:47] <NCommander> ogra: ouch.
[13:47] <ogra> uboot cant achieve that
[13:48] <ogra> by design
[13:48] <NCommander> ogra: u-boot can do raw reads just like redboot.
[13:48] <NCommander> I just like having a filesystem for my files
[13:48] <NCommander> But thats just me.
[13:48] <hrw> ogra: what you use for that 'fast boot'?
[13:49] <hrw> nand read?
[13:49] <lool> NCommander: redboot supports filesystems as well
[13:50] <NCommander> lool: upstream does, but no vendor fork of Redboot I've seen has it :-/
[13:51] <lool> It's not really a problem with redboot though, but with the vendors   :-/
[13:52] <NCommander> lool: indeed. If we had a modern redboot, I suspect my ability to complain about imx51 booting would be severaly reduced
[13:52] <ogra> indeed i like its flexibility
[13:52] <ogra> it still needs to convert from uImage to raw, no ?
[13:52] <ogra> and copy it around in ram
[13:53] <NCommander> ogra: u-boot can do XIP
[13:54] <sveinse> Do you know if there a host graphical debugger (ddd or insight) which can debug arm code for target? (Probably it's a generic host for the GUI part and gdb-arm for the target)
[13:54] <NCommander> sveinse: ddd should be able to use a cross-debugger, but its been awhile since I tried it
[13:54]  * NCommander just got used to using gdb directly; less painful
[13:54]  * sveinse is about to embark on some kernel driver development, and need eyes into the running kernel...
[13:55] <ogra> hrw, redboot ... fast boot paid with zero flexibility
[13:55] <sveinse> I'm going to use JTAG tool + OpenOCD, but I need a GUI frontend for gdb on host
[13:55] <ogra> ******* reminder ubuntu mobile meeting in 5 min in #ubuntu-meeting *******
[13:57] <slapin> hi, all!
[13:59] <slapin> I try to rebuild gtk+2.0 on my SheevaPlug, and it uses -mfpu=vfp for it, is it ok? I could'nt find that Sheeva supports any floating point unit...
[13:59] <lool> slapin: We require vfp nowdays
[13:59] <lool> in Ubuntu that is
[14:00] <slapin> where could I change that globally in my build environment?
[14:01] <lool> slapin: You'd need to rebuild all of Ubuntu
[14:01] <lool> slapin: This is encoded in the toolchain defaults
[14:02] <slapin> lool: is there some automated way to build all ubuntu (at least base system plus some packages)?
[14:02] <slapin> lool: I mean cross-compile
[14:03] <lool> slapin: Cross-compile, not really
[14:03] <lool> there are various tools available to rebuild Ubuntu as a whole, but they are not too clever, so you might have to do that multiple times
[14:04] <slapin> lool: what device is used to build lots of packages reasonably fast for ARM architecture?
[14:05] <slapin> lool: I think it is ok with me, I just want to know which tool is mainstream one
[14:05] <slapin> lool: and what setup is needed.
[14:06] <lool> slapin: We currently build continously
[14:06] <lool> slapin: using real ARM hardware
[14:07] <ogra> using launchpad/soyuz as builder system on top
[14:07] <lool> We tried using both dove and imx51 boards, but I think our build system is mostly imx51 atm
[14:08] <slapin> is it possible to build locally?
[14:09] <lool> slapin: Yes
[14:10] <lool> slapin: In theory you can setup launchpad, albeit that's heavy, or you can use the Debian tools such as wanna-build and dak, but these are a bit hard to setup as well; finally there are some ad hoc rebiuld tools like rebuildd
[14:11] <slapin> lool: 'heavy' is fine with me, is there any docs on how to set up launchpad?
[14:13] <persia> slapin: There's some (limited) docs as a side effect of https://dev.launchpad.net/Getting
[14:19] <slapin> thanks a lot!
[15:05] <plars> ogra: omap image didn't build last night, I assume because of RC (which it is not really included in at the moment).  Any way to force just that one to rebuild?
[15:06] <ogra> plars, we need the livecd-rootfs fix anyway, so i prefer to wait
[15:07] <plars> ogra: ok
[15:07] <ogra> assuming you refer to netbook
[15:07] <plars> ogra: yes
[15:40] <sveinse> lool: Thanks! If you are interested, I can keep you posted on how we solve cross compilation into Ubuntu. Currently it seems that apps built in the cross compiler works directly on target, but I think that's a coincidence that both libc and libstc++ has the same version on the cross and on the native system.
[15:44] <lool> sveinse: Correct; I don't expect too many incompatibilities there, because we try hard to have working binaries, but it's bad for other reasons (you actually want to know aganst what piece everything is built, and wihch features it uses -- toolchain flags and such)
[15:58] <sveinse> lool: Where is the default compile flags (for the native compiler defined)? In the spec file?
[16:00] <lool> The toolchain default to what you compiled it with
[16:01] <sveinse> Ah right, so it adopts its CFLAGS automatically
[16:28] <dmart> NCommander: does OOo build at the moment?  I've been trying to get a build tree for a few days, but I've hit problems
[16:28] <ogra> dmart, it should
[16:28] <lool> dmart: Yes I think so
[16:29] <lool> dmart: Well it's *building* I think
[16:29] <ogra> and it did as well before that minor change upload
[16:29] <NCommander> dmart: in theory.
[16:29] <ogra> after NCommander fixed it
[16:29] <ogra> there was one finished build afaik
[16:29] <NCommander> ogra: you mean blundened it
[16:29] <lool> It's definitely building ATM
[16:30] <ogra> yeah, there was a recent upload
[16:30] <NCommander> dmart: we forced it to -marm. Not a real fix, but works for now
[16:31] <dmart> http://pastebin.ubuntu.com/419326/
[16:31] <dmart> I always get this, whether the -marm workaround is present or not.
[16:31] <dmart> My filesystem should be up to date
[16:31] <lool> ../unxlngr.pro/bin/makedepend: symbol lookup error: ../unxlngr.pro/bin/makedepend: undefined symbol: cppsetup
[16:31] <lool> hmm
[16:31] <ogra> dmart, how far into the build was that ?
[16:32] <ogra> https://edge.launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-7ubuntu3/+build/1698510 says its running since 19th
[16:32] <dmart> Pretty early - no more than 1h in
[16:32] <dmart> Incorrect build-deps (or my filesystem in a mess)
[16:32] <dmart> ?
[16:32] <dmart> This is a lucid chroot running on top of Jaunty in babbage1
[16:33] <ogra> heh
[16:33] <ogra> thats a pretty unpredictable env
[16:34] <ogra> our buildfarm is completely bbg3 on lucid now
[16:34] <persia> I've encountered a number of odd failures running pbuilder in jaunty to build lucid: I've had significantly better success with using qemu-user mode (although that's not a good basis for this specific issue)
[16:34] <ogra> surely not for OO.o, no :)
[16:34] <dmart> OK, maybe I ought to be careful about this
[16:34] <persia> I've been presuming it's due to missing thumb2 support int he jaunty kernel, although I have no basis for this presumption.
[16:34] <dmart> I have loads of babbage1 doing not much :/
[16:35] <persia> dmart: Can you get a 2.6.32 kernel running on them?
[16:35] <dmart> persia: the jaunty kernel should support Thumb-2, but there might be some unfixed issues
[16:35] <persia> if so, you have the basis of a lovely build farm :)
[16:35] <ogra> persia, bbg1 was pre-production HW
[16:35] <dmart> I can maybe run the build on babbage3 and use the babbage1s as distcc slaves
[16:35] <ogra> there can be plenty of silicon issues
[16:36] <dmart> a pretty dumb board can run distccd
[16:36] <ogra> yeah, for distcc that might work
[16:36] <ogra> or icecc
[16:36] <dmart> icecc?
[16:36] <ogra> next gen distcc :)
[16:37]  * dmart googles
[16:37] <dmart> oh, right :)
[16:37] <ogra> NCommander had a setup for his OO.o tests
[16:37] <dmart> For massive C++ compiles distcc can provide quite a boost
[16:38] <NCommander> ogra: dmart: icecc doesn't help much, since then it tries to parallize the things that icecc doesn't do, and the then it goes bad
[16:38] <ogra> ??
[16:38] <ogra> which of the icecc should be distcc now ?
[16:38] <NCommander> ogra: basically, theres no way to tell OOo you only want to parallize the building only the C/C++ builds
[16:38] <NCommander> so it works great for C/C++ modules
[16:38] <NCommander> it gets really bad when it gets to running javac
[16:39]  * ogra still doesnt get what things icecc does that icecc doesnt do
[16:39] <ogra> that sentence made no sense
[16:40] <NCommander> ogra: oh, I fail
[16:40] <NCommander> ogra: basically, the OOo build system is stupid, and can't properly parallize the build so only the C bits are build in parallel
[16:40] <suihkulokki> ofcourse, distcc/icecc don't parallilze javac. just c/c++
[16:40] <ogra> right
[16:41] <ogra> i got *that* part
[16:42] <ogra> the initial sentence was just very confusing
[18:07] <prpplague> ogra: ping
[18:13] <XorA|gone> hey guys is UDS still going ahead as planned considering the chances of airflight being allowed by then seem to be minimal?
[18:14] <lool> XorA|gone: minimal?  according to whom?
[18:14] <XorA|gone> lool: the volcano doesnt seem to be emitting any less ash
[18:15] <lool> Actually it does
[18:15] <XorA|gone> lool: not according to news this afternoon when scotland closed again
[18:15] <lool> I heard at lunch that ashes emissions went significantly down
[18:15] <prpplague> XorA|gone: hey bud
[18:15] <persia> XorA|gone: So, isn't that why the chunnel was dug?
[18:16] <prpplague> XorA|gone: ugh, saw the new dr.who last saturday :(
[18:16] <prpplague> XorA|gone: very disappointed
[18:16] <XorA|gone> persia: yeah thats easy enough for me, I just dont want to be the only guy there :-)
[18:16] <persia> Those of us from far away can fly to somewhere within train distance one way or another
[18:17] <XorA|gone> persia: just checking people are still planning to attend and not move to somewhere more reliable like spain
[18:17] <XorA|gone> as Ill need to book tickets ASAP
[18:17] <lool> it's definitely still planned  :-)
[18:17] <persia> We did spain too recently to repeat
[18:17] <XorA|gone> BBC news if quite defineate on increasing volcano ash again today
[18:18] <persia> (and actually, twice: once andalucia and once catalunya)
[18:19]  * XorA|gone thinks we need an Edinburgh to Holland tunnel
[18:31] <sveinse> The airspace here in Norway has been reopened today. And according to the news, the volcano has gone over to a lava-production phase where the ash production is significantly reduced
[18:34] <Martyn> sveinse: Thank goodness
[18:34] <Martyn> sveinse: But unfortunately the second volcano is starting to swell .. so we're likely going to see a second blast
[19:14] <NCommander> eggonlea: you around?
[19:27] <hrw|gone> XorA|gone: going for UDS?
[19:28] <hrw|gone> XorA|gone: would be great to see at least one known face ;D
[19:31] <ogra_cmpc> hrw|gone, we're not *that* ugly, don't be scared :)
[19:31] <ogra_cmpc> prpplague, hey
[19:31] <ogra_cmpc> (just here for a few mins)
[19:31] <hrw|gone> ogra_cmpc: I did not said that.
[19:32] <ogra_cmpc> though all the hugging might scare you probably *g*
[19:33] <hrw|gone> ogra_cmpc: but when I will arrive at ~21:00 on sunday it would be easier to just call xora and go for a beer then catch someone on irc and then wonder which of guys in lobby was that one
[19:34]  * ogra_cmpc doesnt actually knoe when he arrives (driving by car) but i'm surely up for a beer then :)
[19:34] <hrw|gone> ogra_cmpc: during uds I will meet some familiar faces but connecting faces to irc nicks etc takes time
[19:34] <ogra_cmpc> indeed
[19:34]  * ogra_cmpc knows what you mean
[19:34] <ogra_cmpc> and XorA|gone is easy to memorize :)
[19:35] <hrw|gone> guadec 2007 was great for me - I finally met OpenedHand people after working with them for nearly half year
[19:35] <ogra_cmpc> you will meet some again at UDS
[19:35] <hrw|gone> ogra_cmpc: I first met him in 2006 iirc
[19:35]  * ogra_cmpc met him about a month ago in nice
[19:36] <hrw|gone> ogra_cmpc: so far I do not see ex-OH people on list
[19:36] <hrw|gone> but there is still time - I am not on a list yet too
[19:36] <hrw|gone> waiting for some mails first
[19:37] <ogra_cmpc> not sure they did their paperwork yet ...
[19:37] <hrw|gone> bts got my papers yesterday
[19:37] <ogra_cmpc> but i'm sure neil is coming
[19:40] <prpplague> ogra_cmpc: hey bud
[19:56] <NCommander> asac: so libgphoto2 successed in public devirtualized PPA
[19:56] <NCommander> asac: care to sponsor?
[19:56] <crimsun> I can if you pass me the dsc url
[19:59] <NCommander> asac: crimsun: https://bugs.edge.launchpad.net/ubuntu/+source/libgphoto2/+bug/567422
[19:59] <ubot4> Launchpad bug 567422 in libgphoto2 (Ubuntu) "ARM FTBFS fix for libgphoto2 on lucid (affects: 1)" [Undecided,New]
[20:03] <asac> NCommander: could you check with -release ... i guess this wont be before RC?
[20:04] <NCommander> asac: already did check with release yesterday on fixing this problem this way
[20:04] <NCommander> asac: not sure on uploading it now though
[20:09] <NCommander> asac: we're in pre-release freeze now though, so you can upload now, and if its problematic, it will just sit in the queue until after RC
[20:16] <asac> NCommander: ok. let me test build at least ;)
[21:30] <Sayag_Samuel> hello
[21:30] <Sayag_Samuel> I'm trying to set an USB camera on the beagle board and I have some problems


[14:30] <cpaelzer> OMW, just a sec
[14:31] <slyon> \o
[14:31] <didrocks> o/
[14:32] <sarnold> good morning
[14:33] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:33] <meetingology> Meeting started at 14:33:22 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:33] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:33] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage
[14:33] <cpaelzer> hello MIR party people
[14:33] <cpaelzer> a few have already said hello before I started the logging, so we can start right away
[14:34] <cpaelzer> #topic current component mismatches
[14:34] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:34] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:34] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:34] <cpaelzer> nothing new in non-proposed
[14:34] <slyon> nothing new AFAICT.
[14:34] <slyon> is python-jsonschema already handled?
[14:34] <cpaelzer> lintian continue trying to grow the biggest possible tree :-)
[14:35] <slyon> wrt. lintian graham started the work on the debian-perl MIRs and i'm currently working with olivier to resolve the libregexp-wildcards autopkgtest
[14:35] <cpaelzer> slyon: last week jamespage said he will have a look
[14:35] <slyon> the discussion with the Debian mantainer was negative, so we'll stick with libregexp-wildcards-perl
[14:35] <slyon> ok
[14:35] <cpaelzer> ok wildcards it will be
[14:36] <cpaelzer> then IIRC just add the automated perl autopkgtest
[14:36] <cpaelzer> and it should be ready to go
[14:36] <slyon> ack
[14:36] <sarnold> I lost scrollback so I'm not sure if we've discussed python-jsonschema and its children or not
[14:36] <cpaelzer> jamespage: coreycb: we will continue to leave python-jsonschema  -> webcolors / rfc3987 to you then
[14:36] <cpaelzer> sarnold: yes jamespage said he'll take a look
[14:36] <sarnold> \o/
[14:36] <cpaelzer> might as well be ongoing already without us being aware of details
[14:36] <cpaelzer> next ...
[14:37] <cpaelzer> #topic New MIRs
[14:37] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[14:37] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:37] <cpaelzer> wpe ... again?
[14:37] <sarnold> finished :D
[14:37] <cpaelzer> oh back from security - nice
[14:37] <cpaelzer> let us checkt he right next state
[14:38] <slyon> nice, double ACK
[14:38] <cpaelzer> both got a security ack
[14:38] <coreycb> cpaelzer: are those in excuses?
[14:38] <cpaelzer> coreycb: they are in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:38] <cpaelzer> so they should as well be in excuses I guess
[14:38] <coreycb> thanks
[14:39] <cpaelzer> hmm
[14:39] <cpaelzer> they are not
[14:39] <cpaelzer> odd
[14:39] <cpaelzer> coreycb: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-jsonschema
[14:40] <sarnold> so, should we change both from new -> in progress? or is there a better next step?
[14:40] <cpaelzer> bunch of test issues still
[14:40] <slyon> sarnold: yes. In progress would be the correct status
[14:40] <coreycb> I was working through jsonschema issues with sahara yesterday so maybe similar
[14:40] <cpaelzer> yes coreycb
[14:40] <slyon> for the desktop team to pull the trigger and upload the change that pulls it into main
[14:40] <cpaelzer> ok back to wpe then
[14:41] <cpaelzer> both mostly missed tests
[14:41] <cpaelzer> which got flagged as recommended todo
[14:41] <cpaelzer> Desktop team has filed upstream bugs to add tests in the first place
[14:41] <didrocks> which is an issue with a lot of desktop packages TBH, upstream lack testing spirit
[14:41] <cpaelzer> and tests it (once merged) as part of high level tests where this lib is used
[14:42] <cpaelzer> so I guess this is actually ready for promotion if the team has subscribed already
[14:43] <didrocks> no team subscription, but I think we can let seb128 who will probably handle the promotion, doing both
[14:43] <slyon> should we assign it to seb then?
[14:43] <didrocks> yeah, that would make sense
[14:44] <cpaelzer> I have done so
[14:44] <cpaelzer> and added a clarifying update
[14:44] <cpaelzer> thereby new bugs are depleted
[14:44] <cpaelzer> going on
[14:44] <cpaelzer> #topic Incomplete bugs / questions
[14:44] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:44] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:44] <cpaelzer> wildcards we already mentioned above
[14:45] <slyon> vulkan-tools got a security NACK
[14:45] <cpaelzer> see it
[14:45] <cpaelzer> interesting
[14:45] <cpaelzer> not seen one in a while
[14:45] <cpaelzer> I'll read that later once (if?) I have time
[14:46] <cpaelzer> all other updates are older - or is the lintian -*-perl one new still ...
[14:46] <didrocks> seems it’s really on the lack of maintainance
[14:46] <slyon> no, lintian -*-perl just got a tracking update
[14:46] <cpaelzer> no update substantial in the lintian*perl bug
[14:47] <cpaelzer> #topic MIR related Security Review Queue
[14:47] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[14:47] <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:47] <cpaelzer> Internal link
[14:47] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[14:47] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[14:47] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:47] <cpaelzer> sarnold: I need https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 in that board to prioritize it
[14:47] <slyon> cpaelzer: actually the vulkan NACK seems to be for Bionic only
[14:47] <sarnold> cpaelzer: ack!
[14:47] <slyon> others are still TDB
[14:48] <cpaelzer> slyon: yeah, but that is fine
[14:48] <cpaelzer> slyon: (for here) we only need to identify things we can and should act on
[14:48] <slyon> okay
[14:48] <slyon> so that's back to your team to decide how to proceed
[14:48] <cpaelzer> slyon: vulkan you mean - yeah
[14:48] <slyon> yes
[14:48] <cpaelzer> sarnold: that is the outcome of all our rust talk
[14:48] <sarnold> cpaelzer: https://warthogs.atlassian.net/browse/SEC-1214
[14:49] <cpaelzer> sarnold: it was given an ok on the MIR review, we work on the recommended TODOs already
[14:49] <cpaelzer> thanks
[14:49] <cpaelzer> bumped and commented
[14:50] <sarnold> unfortunately, chrisccoulson wasn't able to get to nullboot before he went on PTO, it'll be a while before that one can get some traction
[14:50] <cpaelzer> we have ~3 weeks to feature freeze
[14:50] <cpaelzer> if you see any of those tagged for FF being expected to be a miss could you let us know next week
[14:50] <sarnold> but iwd, ell, wpe*, have made progress; vulkan-tools NAK, ipmitool is very nearly done (NAK)
[14:50] <cpaelzer> then we can file FFE bugs for them
[14:51] <cpaelzer> and in general - I really do see and appreciate the steady security review progress nowadays
[14:51] <sarnold> amazing how time flies :( yeah, sounds like a good idea
[14:51] <cpaelzer> \o/
[14:51] <cpaelzer> ok next is AOB
[14:51] <cpaelzer> #topic Any other business?
[14:51] <cpaelzer> #endmeeting
[14:51] <meetingology> Meeting ended at 14:51:42 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-02-14.33.moin.txt
[14:51] <cpaelzer> wow
[14:51] <sarnold> heh
[14:51] <cpaelzer> that was too much copy and paste
[14:51] <sarnold> eager to head out? :)
[14:51] <cpaelzer> tell me you have a topic and I'll re-open another one
[14:52] <didrocks> no business allowed :)
[14:52] <sarnold> I actually do ..
[14:52] <didrocks> nothing for me
[14:52] <slyon> haha, nothing from my side
[14:52] <cpaelzer> nothing for me either
[14:52] <cpaelzer> ok and jamespage + joalif are not around today
[14:52] <cpaelzer> well then I'm lucky with my mistake
[14:52] <cpaelzer> enjoy your days please!
[14:52] <slyon> no wait,
[14:52] <cpaelzer> arre
[14:52] <slyon> sarnold: had something
[14:52] <sarnold> I'd like to plant the seed of an idea if there'd be gains in replacing the giant flowchart/state diagram of doom with something more like the kernel team SRU workflow
[14:52]  * didrocks notices cpaelzer ignores sarnold
[14:52] <cpaelzer> too much scrolling here
[14:52] <sarnold> here's a nice example bug https://bugs.launchpad.net/kernel-sru-workflow/+bug/1983335
[14:52] <didrocks> maybe this is way the meeting was closed prematurely :p
[14:52] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status - bonus
[14:52] <meetingology> Meeting started at 14:52:55 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:52] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:53] <sarnold> I'd like to plant the seed of an idea if there'd be gains in replacing the giant flowchart/state diagram of doom with something more like the kernel team SRU workflow
[14:53] <sarnold> here's a nice example bug https://bugs.launchpad.net/kernel-sru-workflow/+bug/1983335
[14:53] <cpaelzer> I missed an "Any other business"
[14:53] <cpaelzer> #topic Any other business?
[14:53] <sarnold> with the different phases of the review spelled out, individuals or teams assigned to each, status indicators on each..
[14:53] <didrocks> oh, basically, all stages in the bug targets?
[14:54] <cpaelzer> has anybody been in volved in creating this and can advise us?
[14:54] <slyon> would be more of a linear process
[14:54] <sarnold> I think it'd complicate things like bionic vulkan-tools, but I think it would have other simplifying efforts
[14:54] <cpaelzer> mutli-release reviews would become multiple bugs
[14:54] <sarnold> but the transition effort might cost more than any of us can afford
[14:54] <didrocks> yeah, I wonder how unlinear would work out, see if we can serialize that to a stack rollbacking to top if needed with higher priority
[14:54] <cpaelzer> which is ok as we mostly review one and then sub-check differences for the others
[14:54] <sarnold> and multi-package reviews might be harder to organize
[14:55] <slyon> right, like all the *-perl packages which we can squash into a single bug
[14:55] <sarnold> we in the security team were working on prepping some metrics and just finding it hard to *count* how many mirs in what states we had..
[14:55] <sarnold> iirc what we had to do launchpad scraping took an hour to execute every week
[14:55] <slyon> but those are still handled individually, so having a separat bug for each of them should still be manageable
[14:55] <cpaelzer> sarnold: and you tihnk counting would be better with this?
[14:56] <cpaelzer> the scraping I mean
[14:56] <sarnold> cpaelzer: well, it's hard to say; in the end we decided to scrap our launchpad scraping and move to jira, but, uh, we found earlier today that relying upon jira isn't without flaws too
[14:56] <cpaelzer> this sounds like workflow optimization which is a thing
[14:57] <cpaelzer> but most likely not our task or duty
[14:57] <sarnold> perhaps, but it is something most of us touch
[14:57] <sarnold> and making the things we touch often a bit nicer has rewards :)
[14:57] <cpaelzer> there might be new work to describe and process workflows, which then I think would provide the stage to renew
[14:57] <sarnold> whether or not this is nicer is another question
[14:57] <cpaelzer> sarnold: I think it comes down to someone finding the time to make a POC on launchpad to show it
[14:58] <sarnold> ah, good point. I hadn't considered that approach, heh
[14:58] <cpaelzer> which I think starts with findin who did it in kernel
[14:58] <cpaelzer> I guess it can all be LP API
[14:58] <cpaelzer> when we consume a new MIR we'd run a tool which adds the stages
[14:58] <cpaelzer> and then assign the review as one stage
[14:59] <cpaelzer> I'm open to discuss/check such a POC but currently consider myself unable to create it
[14:59] <cpaelzer> thanks for birnging the idea up though
[14:59] <cpaelzer> it seems interesting indeed
[14:59] <cpaelzer> having a hard stop now
[14:59] <sarnold> thanks :D
[14:59] <cpaelzer> any other other business?
[14:59] <sarnold> that's it
[14:59] <slyon> nope
[14:59] <didrocks> nothing else
[14:59] <cpaelzer> ok
[14:59] <cpaelzer> then again
[14:59] <cpaelzer> #endmeeting
[14:59] <meetingology> Meeting ended at 14:59:56 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-02-14.52.moin.txt
[15:00] <cpaelzer> thank you all
[15:00] <didrocks> thanks!
[15:00] <slyon> thanks cpaelzer, all!
[15:00] <sarnold> thanks cpaelzer, all :)
[19:00]  * vorlon waves
[19:00] <rbasak> o/
[19:01] <vorlon> good news, everyone! I'm finally logged into the wiki!
[19:01] <vorlon> (though afaik the root issue is still not fixed)
[19:05] <vorlon> waiting to start the meeting until we have quorum
[19:10] <vorlon> rbasak: anything you want to discuss off-book?
[19:13] <rbasak> We need to handle the "New Official Flavor Process Issues" thread
[19:15] <vorlon> from 1-on-1 conversation it sounded like you were planning to take a stab at the revisions, is that correct?
[19:16] <vorlon> fwiw while I can see room for improvement in the doc in terms of ordering / structure of the sections so it's easier to follow, I have a difficult time fulfilling Eickmeyer's request for a "step-by-step" process doc because most of these things can and should happen in parallel
[19:17] <rbasak> I don't think I'm qualified to go into the specifics. But it seems to me that this is mainly a mismatch of expectations rather than really a lack of documentation. Particularly because a new flavor is such a rare event, realistically I think the docs will always be out of date.
[19:17] <rbasak> Instead, I think we need to focus on communication. So the key thing is to document that potential flavors should get in touch.
[19:17] <rbasak> And outline how that is to be done.
[19:18] <rbasak> It sounded like Erich would be OK with this.
[19:18] <vorlon> ok
[19:19] <rbasak> Of course we should improve the docs when we have specific things that obviously should be fixed.
[19:19] <vorlon> you still good to take the first pass at that?
[19:19] <rbasak> Sure.
[19:20] <vorlon> thanks
[19:20] <vorlon> anything else?  otherwise since we're not looking quorate I'm going to go work on an ubuntu-release-upgrader SRU
[19:22] <rbasak> I continue to work on the third party repository task.
[19:22] <rbasak> I don't think there's anything else. Thanks!
[19:22] <vorlon> thank you!