[07:29] <siji> How to do the screen alignment (LCD /touch 7") in Ubuntu
[07:30] <siji> My ubuntu natty on beagle board needs some left aligment
[07:30] <siji> I have tried to modify /sys/devices/omapdss/display0/timings , but not happening
[07:59] <siji> persia, there?
[08:00] <persia> siji, Yeah, but a bit busy just now.
[08:00] <persia> Just ask your question: maybe someone else has an answer.
[08:00] <siji> ok persia carry on
[08:01] <siji> I have already put the question here :)
[08:01] <persia> Ah, I thought it might be something else.  I don't know the answer to that one anyway.
[08:03] <siji> ok
[08:12] <lilstevie> howdy persia
[08:14] <persia> Hey lilstevie
[08:15] <lilstevie> persia: with that source package the config needs to be edited
[08:15] <lilstevie> kernel config in its current form will gimp networking (I forgot about it)
[08:16] <persia> Did you sort the rest of it as well?  I should have time to review it again in a couple hours.
[08:18] <lilstevie> what was wrong with the rest of it?
[08:20] <persia> lilstevie, I can check my logs, but I remember package names, consolidation between two models, changelog.
[08:21] <lilstevie> ah yeah
[08:22] <lilstevie> I remember niw
[08:22] <lilstevie> now*
[08:22] <lilstevie> also had problems with using a ppa for hw enablement, I found out standard ppa accounts don't have access to armel builders :p
[08:24] <persia> Yet another reason why the archive is superior to PPAs.
[08:25] <lilstevie> heh
[08:25] <sundar_> hi all
[08:25] <lilstevie> it was more a stopgap solution until things make it into backports
[08:26] <sundar_> i am not sure if i am on the right channel to ask this question. I am on an embedded arm board running linux. I would like to open a virtual console on ctrl+alt+f1. any idea how i can achieve this?
[08:26] <persia> Backports is two testers away once it hits the archives.
[08:26] <lilstevie> oh really?
[08:26] <persia> sundar_, If you're running some flavour of Ubuntu, it ought just work.  if not, I'm unsure if we can help you.
[08:27] <lilstevie> btw I have the firmware issue taken care of :) injection done at install time
[08:27] <lilstevie> from android image
[08:27] <persia> lilstevie, Yep.  Just needs a backports request, and two people to confirm the posted package works.  Then a backporter checks for sanity, and does the backport.
[08:27] <lilstevie> ok well how do we get 2 testers :) cause I have about 250 users
[08:27] <sundar_> persia, thanks for quick response. I am running a custom compiled linux kernel and cutom built rootfs
[08:28] <lilstevie> and this kernel is newer than what they are currently running
[08:29] <persia> lilstevie, We get the kernel in the archive, we prepare a backports bug with instructions on how to get the kernel, and we hope 1% of your users are willing to comment on the backports bug.
[08:29] <lilstevie> also most of the ac100 stuff in flash kernel will work for this device
[08:29] <persia> You'll want to prepare a patch that lets a single flash-kernel script work for both devices.
[08:29] <sundar_> persia, if i were to do it on a ubuntu based board, how can i do it?
[08:29] <ogra_> already existing :)
[08:29] <lilstevie> persia: ok awesome :) well I am sure I can get a few
[08:30] <lilstevie> ogra_: what is already existing?
[08:30] <persia> sundar_, It would just work.  You can compare your X config and VC config to Ubuntu's, but I wouldn't know how.
[08:30] <ogra_> juliank has merged my ac100 stuff in the "flash-kernel-next" tree
[08:30] <ogra_> in a way that it handles all android based devices
[08:30]  * persia goes back to try to finish stuff and be honest about the "couple hours" above
[08:30] <ogra_> well, everything that can use abootimg images
[08:30] <lilstevie> ogra_: I only need 1 thing for the tf
[08:31] <lilstevie> my SOS and LNX kernels are available, and depending on config (chosen at install time) depends where the primary is
[08:31] <lilstevie> but on the pure linux cfg LNX boots normal and SOS boots in single user mode
[08:36] <lilstevie> ogra_: is flash-kernel-next available anywhere?
[08:36] <ogra_> yes, lool has a branch on the debian git server somewhere
[08:36] <ogra_> its not used anywhere yet
[08:36] <lilstevie> ok
[08:37] <ogra_> i.e. not packaged
[08:37] <ogra_> but it will be the new flash-kernel (note that i made up the -next)
[08:37] <lilstevie> heh
[08:37] <lilstevie> when should that be out?
[08:38] <lilstevie> this kern has some huge improvements over the one that is currently in use :p
[08:38] <lilstevie> faster boot time, sound, improved handling of the keyboard
[08:38] <lilstevie> etc
[08:39] <siji> persia, it's solved :)
[08:44] <ogra_> lilstevie, not sure if it will ever hit armel in debian
[08:45] <ogra_> there are to many old arches in it that would need very very heavy testing
[08:45] <ogra_> i suspect we will see it in debian armhf before where you dont have to retain that much backwards compatibility
[08:46] <lilstevie> hmm
[08:46] <ogra_> but that a decision of debian
[08:46] <lilstevie> what about for us?
[08:46] <ogra_> i personally would like to switch to the next gen version next release
[08:46] <ogra_> i wanted to do it this time but got to much other stuff on my plate this round
[08:50] <lilstevie> ah I see
[08:51] <lilstevie> just would be nice to have an easier solution while trying to get my tf kernel into backports
[09:10] <lilstevie> persia, I am working on fixing up those things now
[09:50] <lool> lilstevie: it's in the official flash-kernel.git
[09:52] <lilstevie> lool, ok cool, just wondering whether we will see support in natty
[09:55] <Loqus> Has anyone got any experience using a Gumstix platform, with 11.04, and 802.1q VLANs?
[09:55] <lilstevie> persia, uploading the new source now'
[09:57] <lool> lilstevie: *natty*?  no way
[09:58] <lool> lilstevie: I mean, you could work on backports if you like, but this is a critical piece of infrastructure and there are major changes in there
[09:58] <lool> it's not that it's huge, but you wouldn't backport e.g. grub 2 to a grub 1-based ubuntu release that easily
[09:58] <lool> Loqus: I do have gumstix but didn't try VLANs, they don't work>
[09:59] <lool> they don't work?
[09:59] <Loqus> Well, if I use Angstrom:
[10:00] <Loqus> the vanilla supplied distro, the package manager doesn't heven have the module in its feeds.
[10:00] <Loqus> ...under my desktop ubuntu environment I would get the module with "apt-get install vlan", then modprobe support into the kernel "modprobe 8021q", the use "vconfig add eth0 11" to add a virtual LAN adaptor on the Virtual LAN ID of 11.
[10:01] <lool> ok, that should work with an Ubuntu armel install too
[10:01] <Loqus> When I created a 11.04 rootfs with rootstock, I had no option but to use the 2.6.36 kernel from bitbake because it (I'm told) isn't up to 2.6.38 yet
[10:01] <lilstevie> lool, ok, the only reason I was wondering is cause I am working on bringing my kernel to backports for natty for the transformer
[10:02] <lool> lilstevie: It might indeed be a better idea to base of tip and backport that; just dont expect it in official natty-updates
[10:03] <lilstevie> tip?
[10:03] <lool> A natty base is not in itself a problem, I just wanted to underline that the stable update policy doesn't leave room for intrusive changes like a flash-kernel change
[10:03] <lool> lilstevie: I mean git
[10:03] <lool> tip of git
[10:03] <lilstevie> ah
[10:03] <lilstevie> kk
[10:04] <lilstevie> lool,  so you have no problems with getting it into backports then :)
[10:05] <lool> It's unlikely that someone finds the time to confirm that there is no regression with any of the supported platforms in a backported package
[10:05] <lool> I suspect you would be masking support for some platforms in the backport
[10:05] <lool> I have no objection to a PPA   ;-)
[10:06] <lilstevie> I don't have an armel supporting PPA
[10:06] <lool> it's arch:all
[10:06] <lilstevie> :(
[10:06] <lool> or is it
[10:06] <lilstevie> ah
[10:06] <lool> oh no it's not
[10:06] <lilstevie> :)
[10:06] <lool> but it's actually arch:all  :-)
[10:06] <ogra_> lool, do you see a chance for a flash-kernel-ng package in debian ?
[10:06] <lool> it's only present on certain architectures, but it only contains arch: all data
[10:07] <lool> -ng?
[10:07] <lilstevie> ok so it is still a script rather than a binary
[10:07] <lilstevie> next generation?
[10:07] <ogra_> well, so we can keep the old one around
[10:07] <ogra_> -ng or -next or -new
[10:07] <lool> ogra_: just don't sync it if you dont want the new one?
[10:07] <ogra_> lool, the new one is in debian ?
[10:07] <lool> no
[10:07] <ogra_> thats what i mean
[10:07] <ogra_> i know its used in armhf
[10:08] <lool> oh god, I really need to go test it and upload it
[10:08] <lool> I'll JFDI
[10:08] <ogra_> well, do you see a chance to get it tested on all arches soon ?
[10:08] <lilstevie> when is ubuntu transitioning to hard float
[10:08] <ogra_> ask infinity ;)
[10:08] <lool> I can't ever test it on all platforms, but I can upload it to experimental and send a call for testing afterwards
[10:08] <ogra_> he is working on it this week
[10:09] <ogra_> lool, awesome
[10:09] <lilstevie> heh cool
[10:09] <lool> TBH, I took responsibility for this rewrite and I have not secured the time to actually make it happen in Debain
[10:09] <lool> so I am really late in this Debian work of mine
[10:09] <ogra_> lool, well, i want to switch in P in any case
[10:09] <lilstevie> would be cool to see how much of a difference there is performance wise
[10:09] <lool> ogra_: Ideally, we'd switch in oneiric to have less intrusive changes in oneiric+1
[10:09] <ogra_> and i will ignore debian if they arent on the new version
[10:10] <lool> lilstevie: performance wise?
[10:10] <lool> lilstevie: oh armhf
[10:10] <lool> lilstevie: in Ubuntu, you'll see little difference
[10:10] <lilstevie> lool,  hard float
[10:10] <lilstevie> yeh
[10:10] <lilstevie> heh
[10:10] <lool> but in Debian it's a huge gap
[10:10] <lilstevie> debian will though
[10:10] <lool> yes
[10:10] <lilstevie> hf is a huge jump over armv5t
[10:11] <lool> armv4t!
[10:11] <lilstevie> oh shoot
[10:11] <lilstevie> that far behind
[10:11] <lool> Yeah, I can't really support people still caring for ARMv4
[10:12] <lilstevie> armv6 is the minimum I would support but even then
[10:15] <suihkulokki> ARMv5 has a wide install base, and ARMv4t misses only few instructions from ARMv5
[10:15] <suihkulokki> CLZ, PLD being ones usually bumped into
[10:16] <lilstevie> I wish tegra had NEON
[10:17] <suihkulokki> People have strange ideas that incredimental ARMvX versions give revolutional performance increases
[10:17] <suihkulokki> I guess that is successful marketing from ARM =)
[10:18] <lilstevie> heh
[10:18] <lilstevie> there are some things that do have performance increases
[10:18] <lilstevie> t2 being one of them
[10:19] <suihkulokki> but if you have an O(n^n) performance problem you still have it in T2 =)
[10:20] <lilstevie> heh
[10:20] <lilstevie> aside from things like that though t2+NEON is faster than the equiv for armv6
[10:21] <suihkulokki> NEON is good, but you essentially need to some handwritten code take advantage of it
[10:21] <lilstevie> by equiv I mean the same program compiled without t2 and NEON
[10:22] <lilstevie> arm-darwin-gcc takes good advantage of it
[10:22] <suihkulokki> just compiling generic C code wit neon is not going to be huge performance win
[10:22] <suihkulokki> chances that gcc will autovectorize is unlikely
[10:34] <lilstevie> persia, when you are about ping
[13:34] <persia> lilstevie, Sorry: that took much longer than I thought it would.
[13:35] <lilstevie> heh thats cool
[13:35] <lilstevie> same location as last time
[13:37] <persia> tegra-transformer?
[13:40] <lilstevie> yep
[13:40] <lilstevie> persia: that is what we discussed yes?
[13:41] <persia> I was hoping for just "transformer", but this might work: we can see what the archive-admins say if I don't find anything else.
[13:41] <lilstevie> ok,
[13:41] <lilstevie> transformer is fine
[13:41] <persia> Yeah, but not worth rebuilding if this can pass.
[13:41] <lilstevie> if needed
[13:42] <lilstevie> heh :)
[13:42] <persia> If there's something else to fix, then it makes sense to do both at once.
[13:42] <lilstevie> ok
[13:42] <persia> Might be worth a versioned recommends on flash-kernel, for the version that supports the transformer.
[13:43] <persia> Mind you, this just complicates backports, so it may not be worthwhile.
[13:43] <lilstevie> heh
[13:43] <persia> You still have "TBD" as the board identifier.  Dunno if that ought be "transformer", or if you don't care.
[13:43] <persia> Easily fixed in an update, and not important though.
[13:44] <lilstevie> heh
[13:44] <persia> There's some other irregularities in the descriptions, like recommending installation of the "linux-tegra" metapackage, which doesn't exist (and won't).
[13:45] <lilstevie> ok, well that was just from building
[13:45] <lilstevie> to the instructions
[13:46] <persia> Yeah, the instructions need extension: it leaves a few things messy still :(
[13:46] <lilstevie> heh
[13:47] <persia> But that's all just textual: I haven't found anything functional yet.
[13:47] <ogra_> mahmoh, yo, did you recently say you plan to use elevator=noop on server or was that deadline ?
[13:47] <mahmoh> ogra_: I've been testing with deadline
[13:47] <ogra_> k
[13:47] <lilstevie> persia: :)
[13:47] <ogra_> i just ran into kernel bug 15426 here
[13:47] <ubot2> Launchpad bug 15426 in kdebase "kdesu (dup-of: 15001)" [Medium,Invalid] https://launchpad.net/bugs/15426
[13:47] <ubot2> Launchpad bug 15001 in kdebase "Administrator mode not working" [Critical,Fix released] https://launchpad.net/bugs/15001
[13:47] <ogra_> bah
[13:48] <ogra_> https://bugzilla.kernel.org/show_bug.cgi?id=15426
[13:48] <ubot2> bugzilla.kernel.org bug 15426 in VFS "Running many copies of bonnie++ on different filesystems seems to deadlock in sync" [Normal,New]
[13:48] <ogra_> which causes bug 624877
[13:48] <ubot2> Launchpad bug 624877 in linux "INFO: task dpkg:23317 blocked for more than 120 seconds." [Medium,Confirmed] https://launchpad.net/bugs/624877
[13:48] <ogra_> seems the only scheduler i dont get that issue is cfq here
[13:51] <mahmoh> ogra_: that vfs layer bug looks familiar (really familiar in fact) but cfq may just reduce your likelihood of hitting it
[13:52] <ogra_> yeah, that could indeed be
[13:52] <ogra_> well, keep an eye open for it in your server testing ;)
[13:52] <mahmoh> ogra_: if it is the same bug it affects ext3/4 and should be fixed in two months or so
[13:53] <ogra_> i wonder if we should actually switch to cfq on the desktop images
[13:53] <ogra_> ah
[13:53] <mahmoh> ogra_: I've already hit it in another project, that's why it's getting fixed ;)
[13:53] <ogra_> seems many people hit it already according to the different open bugs :)
[13:53] <mahmoh> ogra_: I thought the desktop image is cfq already?  the x86 image is so.
[13:53] <ogra_> not armel
[13:54] <mahmoh> yeah, it's a bad problem
[13:54] <ogra_> we use SD cards
[13:54] <mahmoh> interesting, so what's the benefit of noop vs. cfq on an sd card?
[13:54] <ogra_> with rootfs on SD noop is what you want
[13:54] <ogra_> or deadline
[13:54] <ogra_> the reading and writing is different on MMC than on HDD
[13:55] <mahmoh> write out everything at once, avoid thrashing on the SD?
[13:55] <ogra_> leave the caching to the HW, to let it do its wear leveling
[13:55] <ogra_> we also adjust commit times etc
[13:56] <ogra_> which means you sould always properly shut down ;)
[13:58] <mahmoh> ogra_: so for the arm server kernel (whatever that is), SD won't really be a good root option, that's why I'm pushing for at least a different kernel command line add (elevator=deadline, preempt=0) if not a different kernel all together
[13:58] <ogra_> deadline is fine for Sd as well
[13:58] <ogra_> noop is better but deadline is ok, we should just set that cmdline on all server builds
[13:58] <mahmoh> the arm server kernel should look more like the x86 server kernel than the arm preinstalled image kernel that runs off of sd
[13:59] <persia> lilstevie, I don't see anything else from source inspection.  I've started a build, but I expect to be asleep before it finishes.  I'll let you know if I find anything from the build in the morning.
[13:59] <ogra_> unless you can convince the kernel team to actually roll a -server binary indeed :)
[13:59] <lilstevie> persia: how long it usually take?
[13:59] <persia> mahmoh, So, the "ARM Server" image is a preinstall that runs off SD :)
[14:00] <persia> lilstevie, I'm guessing 2-3 hours, but maybe even 4.
[14:00] <ogra_> well, that will likely change to alternate at some point
[14:00] <mahmoh> they're the one's rolling the kernels?
[14:00] <ogra_> kernel team ? yeah
[14:00] <mahmoh> persia: I'm just looking for a server kernel that can be installed via net-install
[14:00] <persia> ogra_, Even so, for some targets it ends up still being installed to SD.  Depends on the device.
[14:00] <ogra_> linux and linux-ti-omap4
[14:00] <ogra_> persia, sure
[14:00] <lilstevie> persia: oh, one of the normal build systems
[14:01] <persia> mahmoh, Or apt-get, sure.  To support net-install probably needs some fiddling, but nothing too outrageous.
[14:01] <ogra_> we only have the preinstalled server images atm because it was easier to achieve and needs a lot less time for QA
[14:01] <persia> lilstevie, Yeah, just one of my boards that I use for building stuff.  I don't have any magic :p
[14:01] <mahmoh> tasksel ubuntu-server should install a server kernel or apt-get it sep. yes
[14:01] <ogra_> i dont expect it to stay like that forever :)
[14:01] <mahmoh> the sooner the better, I have a bug already but no action, :(
[14:01] <lilstevie> persia: my machine takes half an our but that is cross compiling
[14:01] <persia> I expect server to stay preinstalled until there is hardware that doesn't need preinstall available.
[14:02] <ogra_> right
[14:02] <ogra_> which is likely the next release :)
[14:02] <persia> lilstevie, Yeah, well, that's not quite the same as what the buildds will do :)
[14:02] <lilstevie> persia: hehe
[14:02] <persia> ogra_, With luck, but I won't hold my breath.
[14:03] <lilstevie> persia: well I will be unavailable most of the day tomorrow, uni day
[14:03] <ogra_> no, thats also bad for smoking
[14:03] <ogra_> (holding your breath i mean)
[14:03] <persia> lilstevie, No worries.  We're not tight on a deadline.  Ping me when you get back.
[14:04] <persia> ogra_, See, I figure developing software for hardware that is merely theoretical is *good* for smoking: significantly increased chance of getting magic blue smoke.
[14:05] <ogra_> sure, as long as you dont hold your breath until the HW exists at least :)
[14:05] <lilstevie> persia: well I will be here probably from 4 or 5
[14:05] <persia> lilstevie, In that case, I'll probably get back a bit later than you (it's only +9 here), and catch you when I do.
[14:06] <lilstevie> heh no problems :)
[14:06] <persia> ogra_, I'm not certain that holding one's breath correlates with release of magic blue smoke, although out of perversity, attempting to inhale magic blue smoke may potentially extend component lifespan.
[14:06] <ogra_> GrueMaster, can you make a note to monitor dmesg for "hung task" messages (like in bug 624877) in your next dist-upgrade test ?
[14:06] <ubot2> Launchpad bug 624877 in linux "INFO: task dpkg:23317 blocked for more than 120 seconds." [Medium,Confirmed] https://launchpad.net/bugs/624877
[14:06] <ogra_> i want to know if that also happens on panda
[14:07] <ogra_> (i see it a lot on ac100 which uses largely the same kernel config as omap4 nowadays)
[14:08] <ogra_> if thats the case we really need to change the default scheduler
[14:09] <GrueMaster> ogra_: I have seen it during Natty.  I also see it when running IO tests on oneiric.
[14:10] <ogra_> ok
[14:11] <ogra_> thats bad :)
[14:11] <lilstevie> persia: so what is so special about this build?
[14:12] <persia> lilstevie, Nothing: it's just building for oneiric/armel on oneiric/armel, in an environment as close to that of the buildds as I know how to generate.
[14:12] <lilstevie> ah
[14:14] <persia> The idea being to catch anything before it is submitted, as this makes it less likely the archive admins will reject it with prejudice.
[14:14] <persia> Kernels sponsored by me are likely to get a special double-check, as the last time I uploaded a kernel, it FTBFS, which was a bit embarassing.
[14:15] <lilstevie> heh
[14:15] <lilstevie> well I noticed one issue with this tree
[14:15] <persia> Which?
[14:16] <lilstevie> make mrproper breaks shit
[14:16] <lilstevie> I have no idea why
[14:16] <lilstevie> or even how
[14:16] <persia> !ohmy > lilstevie
[14:16] <ubot2> lilstevie, please see my private message
[14:16] <persia> Hrm?  What's "make mrproper" supposed to do?
[14:17] <lilstevie> makes the entire tree "virgin"
[14:17] <persia> Ah, yeah, a pristine tree is kinda useful.
[14:17] <lilstevie> but it breaks it
[14:18] <ogra_> whats embarrasing about FTBFS kernels ?
[14:18] <lilstevie> ogra_: I guess sponsoring it
[14:18] <ogra_> pfft
[14:19] <persia> ogra_, Archive Admins suggesting I need to do more build testing, mostly.
[14:20] <ogra_> pfft
[14:20] <persia> Yeah, well.  Some of us understand the concept called "shame", and use it to improve our work.
[14:22] <ogra_> well, its not that i dont feel shame ... but i'm not embarrased by FTBFS of something that takes huge efforts to build at home ...
[14:22] <infinity> How Japanese of you.
[14:22] <ogra_> ---compared to just uploading it and let it fail
[14:23] <persia> ogra_, Um, except folk might be using it, and -meta skew is annoying, etc.
[14:23] <ogra_> pfft ... users
[14:23] <persia> Probably builds faster at home than on the buildds anyway, given the current buildd HW.
[14:23] <persia> Some folk subscribe to the philosophy that users are a priority, even :p
[15:01] <GrueMaster> mahmoh: Any luck getting ipv6 tests going?
[15:50] <mahmoh> GrueMaster: haven't tried ipv6, unsure if our local net supports it
[16:03] <GrueMaster> mahmoh: You were going to work on getting the tahi.org testsuite converted.
[16:03] <mahmoh> GrueMaster: I was going to take a look yes, still on todo ;)
[16:03] <GrueMaster> I can run it.
[16:03] <mahmoh> GrueMaster: the u-boot bugs are bogging me down
[16:19]  * ogra_ glares at the bottom of https://launchpad.net/project-rootstock/trunk/+ubuntupkg
[16:19] <ogra_> why does ramana own all these packages ?
[16:21] <GrueMaster> bug 819899 bug 819900
[16:21] <ubot2> Launchpad bug 819899 in livecd-rootfs "package pools need to correctly parse override info to create tasks" [Medium,In progress] https://launchpad.net/bugs/819899
[16:21] <ubot2> Launchpad bug 819900 in livecd-rootfs "package pool implementation needs to update apt" [Medium,In progress] https://launchpad.net/bugs/819900
[16:23]  * GrueMaster thanks ubot2.
[16:27] <persia> ogra_, Report a bug: might be a DB offset issue.
[16:27] <ogra_> well, i asked in #launchpad but got no answer
[16:27] <ogra_> its likely a bug
[16:29] <persia> Poke abently if you want an answer.
[16:30] <persia> lilstevie, So, I didn't end up happily going to sleep whist this compiled.  Firstly, there's calls to ccache inserted in various places, which breaks.  After removing those, there's hard dependencies on cross-compilation stuff, which makes it not build.
[16:30] <persia> I'll still try to catch you tomorrow, but if you're up late, or you check backscroll ...
[16:39] <Loqus> Is anyone using a Tobi Duo
[16:39] <Loqus> ?
[16:42] <GrueMaster> Loqus: ???
[16:42]  * ogra_ guesses GrueMaster's wife uses a tobin from time to time, but whats a tobi ?
[16:43]  * GrueMaster doesn't get used often enough.
[16:43] <ogra_> lol
[16:43] <ogra_> oh
[16:43] <ogra_> an addon board for the gumstix
[16:44] <ogra_> i dont think we even have many gumstix users around here (i would be happy to be wrong indeed)
[16:44]  * GrueMaster has been called many things, but never a board.
[16:44] <ogra_> you would have to slightly work on your shape to be called a board i guess
[16:45] <GrueMaster> (although some ask how the "twins" are doing, either in reference to my jolly size, or moobs - unsure which).
[16:45] <Loqus> I was asking in #gumstix, but they are a bunch of akfkers ;)
[16:45]  * GrueMaster reverts back to image testing before the level of conversation degrades any further.  :P
[16:45]  * ogra_ waits for persia
[16:46] <Loqus> ...yeah, it'sa duel NIC expansion board for the Gumstix... I've moved over from Angstrom to Ubuntu for Arm.
[16:47] <persia> Loqus, Are the NICs recognised, or is the kernel missing the driver?
[16:47] <ogra_> tsk
[16:47] <ogra_> i had a ohmy for less !
[16:48] <Loqus> I don't know... in the wisdom of whoever designed this board, it doesn't have any other console interface, except the NICs. I was asking in case someone knew that i had to modify the board support driver in some way,
[16:49]  * persia is tired and doesn't get the reference, so the offender is free.  Others are welcome to hint about channel guidelines if they like.
[16:49] <Loqus> I *think* that one of them is requesting a DHCP address, but I'm not sure on that one...
[16:49] <ogra_> heh
[16:49] <persia> Loqus, Do you have a DHCP server?
[16:49] <Loqus> yes
[16:49] <Loqus> SSH on the address which is is given, but not connecting
[16:50] <persia> If not, try setting an address in /etc/network/interfaces (the interfaces(5) manpage explains the format).
[16:50] <persia> Do you have openssh-server installed?
[16:50] <Loqus> setting it statically?
[16:50] <Loqus> yes
[16:50] <Loqus> If I pop the board of the Tobi Duo (duel NIC) and put it on a single NIC Tbi, it boots just fine
[16:51] <Loqus> ...the IP is differen because of the different MAC, but aside from that no changes to the FS or kernel
[16:51] <ogra_> is your power supply able to cope with the additional power needs from the board ?
[16:52] <Loqus> ...I'll admit that asking here was a long shot - just in case someone knew that there was an extra module or somethign I had to include.
[16:52] <Loqus> ^Yes, PSU is rated to about 20 amps :)
[16:58] <hank_> I am looking for the source code to build natty Narwhal (Ubuntu 11.04) for omap4. Can someone help me to locate the source?
[17:00] <persia> hank_, So, we typically distribute binary packages, and adjust them one-by-one, using something like `apt-get source ${PACKAGE}` or `bzr branch lp:ubuntu/${PACKAGE}` to get the source for a specific package.
[17:01] <persia> Most of the sources for packages in the images is also available as CD images, from http://cdimage.ubuntu.com/source/current/source/
[17:01] <persia> But that's not usually the easiest way to sort things.
[17:01] <lilstevie> who highlighted me before? client glitched out
[17:02] <persia> lilstevie, I did.  I didn't get to bed, the compile broke first because it was using ccache, and then, after fixing that, because it was looking for cross-compiling stuff.
[17:02] <persia> Back to you :)
[17:02] <lilstevie> heh :)
[17:03] <lilstevie> ok so no ccache cause you don't use it :)
[17:03] <lilstevie> what cross_compile stuff though
[17:03] <persia> hank_, So, what's your ultimate goal?  Would a prebuilt environment work for you?
[17:04] <hank_> persia, I want to cross compile into omap4, currently, downloaded 10.10 soruce, wish to do 11.04. Does that mean I only need 11.04 kernel?
[17:04] <ogra_> what exactly do you want to cross compile and why
[17:05] <persia> 1) What's your host environment?  2) Once you're done cross-compiling, what do you expect to get?
[17:06] <persia> hank_, And no, we don't want the details of your code, if you're working on a secret project: just a general idea so we can give the best advice for your needs.
[17:06] <hank_> ogra_, and persia, Host is a OMAP4 on panda board, prefer to do on x-86 platform because of performance. Finally boot into pandaboard.
[17:07] <persia> hank_, Are you running Ubuntu on the x86 host?  If so, which release?
[17:07] <hank_> persia, I am on 10.10 release on x-86 host.
[17:07] <ogra_> and what do you want to compile ? we offer binaries for all the source you can download already, do you want to change something existing or do you want to cross build some new code that isnt in ubuntu ?
[17:09] <hank_> ogra_,Cross compile with my specific configuration for the embedded.
[17:09] <persia> Aha.
[17:09] <persia> hank_, So, we usually say "We don't do embedded", but our definition is devices with <256M and no MMU, which may not match yours.
[17:10] <ogra_> given it is a panda ...
[17:10] <persia> We don't actually have any facility to rebuild the entire rootfs with different configuration defaults: instead our software stack is organised into packages, each of which would need customisation and rebuild if you need to change things at that level.
[17:11] <persia> We strive to have all the packages be as flexible as possible, so often you can just have a settings package that can change some or all of the defaults, but this is documented in a per-package manner, rather than the all-at-once model that one might have for e.g. LTIB
[17:12] <hank_> persia, and ogra_, Omap4 manufacturer TI has sent me to chat on this channel. Does this mean I should get back to TI with my issue?
[17:13] <persia> hank_, Not necessarily :)
[17:13] <ogra_> i dont think av500 works for TI :)
[17:13] <persia> We're happy to help get you a working rootfs for your pandaboard.
[17:13] <persia> But we use a different model of development, which makes it a bit different from traditional "embedded" environments.
[17:16] <persia> hank_, So, if you want to deploy something desktop-like, we'll recommend you start from the Ubuntu netbook image for 11.04.  Then use the armel cross-compiler distributed with Ubuntu 10.10 to rebuild any packages you want to change.  Install the rebuilt packages into the target, and you ought see the behaviour change.
[17:17] <persia> If you want something smaller, you might start from the headless image, which is a significantly smaller base.
[17:17] <hank_> Thanks, persia. As far as I am concern, I wish to start out from a set of source that has been developed to work with panda board.
[17:18] <ogra_> hank_, like that https://wiki.ubuntu.com/ARM/OMAP ?
[17:19] <hank_> persia, I have tried both notebook 11.04 and 10.10 pre-build images. 11.04 is more perferrable than 10.10 because I can restart from cold with 11.04.
[17:19] <persia> hank_, Well, OK.  Check the manifests from the image download page, and get the source for the packages concerned, from any of the ISOs I mentioned earlier, archive.ubuntu.com/ubuntu/pool/*/*/*/${PACKAGE}.dsc, or ports.ubuntu.com (same path as archive).
[17:20] <persia> We don't either create or build any packages specifically for the pandaboard, but rather attempt to ensure that all the packages in Ubuntu also work with the pandaboard.
[17:20] <ogra_> apart from kernel and bootloader indeed :)
[17:21] <persia> So, for the pandaboard, 11.04 has much more complete porting, and seems to work more reliably.  Last I heard, TI hadn't released some of the binary drivers for it, so if you need certain functions, you may need 10.10 (someone please correct me if I'm mistaken)
[17:21] <ogra_> the binary drivers are fine, the video codecs arent
[17:21] <persia> Oh, heh.  Yeah, bootloader/kernel are device specific (although we consider this a bug)
[17:21] <ogra_> in natty that is
[17:21] <persia> ogra_, Thanks for the clarification.
[17:22] <GrueMaster> The only thing I know of that doesn't work ootb on natty is BlueTooth, but there is some workaround for that which requires pulling a small program from gitorious.
[17:22] <GrueMaster> And video codecs, of course.
[17:22] <hank_> Thanks, persia and ogra_. I will view the desc content and try to get the source. Appreciate it.
[17:23] <ogra_> come back if you have more questions :)
[17:23] <persia> hank_, Good luck.  If you change your mind about rebuilding *everything*, let us know, and we'd be happy to help you with more specific goals.
[17:23] <GrueMaster> Anyone have any ideas for testing ubuntu-core (beyond what I have documented at http://testcases.qa.ubuntu.com/Install/ARM/Core )?
[17:23]  * ogra_ goes reading
[17:24] <persia> GrueMaster, I've been thinking about that much of the day, and came to the conclusion it might be untestable.
[17:24] <ogra_> well, that looks like a good attempt
[17:24] <hank_> Thanks for the insights, persia.
[17:24] <ogra_> you at least test that apt works this way
[17:24] <persia> Unless I'm confused, the only packages of interest in core that aren't tested by the process of creating all the other images are mountall, ifupdown, and upstart.
[17:25] <GrueMaster> We should have some tests for the core apps (not necessarily for this release, but in the future).
[17:25] <persia> And these can only be tested if it's booted, which this image doesn't support.
[17:25] <ogra_> well, what are the core apps ? thats all super low level
[17:25] <ogra_> what do you want to test ? ls ?
[17:26] <GrueMaster> I have no idea.  That is why I am asking.
[17:26] <persia> GrueMaster, Also, do you think it's worth expanding the instructions at https://wiki.ubuntu.com/Core ?
[17:26] <ogra_> i think apt is a good usecase
[17:26] <persia> apt is the *key* usecase, but I can't imagine that not working if we ended up with any of the other images.
[17:27] <ogra_> there are probably more than that, but wasnt the purpose of core to be exactly enough OS to be able to run apt to install additional stuff ?
[17:27] <ogra_> right
[17:28] <GrueMaster> I was thinking of more of a unified test.  Apt is a good one, because if it breaks here, it usually indicates a missing dependency or something.
[17:29] <ogra_> GrueMaster, oh, typo ... resolf should be resolv
[17:29] <GrueMaster> Kind of like with the desktop images.  If X isn't installed, the gui won't boot.
[17:29] <ogra_> and i'm not sure you still need to copy it actually
[17:30] <ogra_> i havent had to do that for ages in a fresh debootstrapped chroot ... though live-build might remove it
[17:30] <ogra_> oh, and the bind mounting will definitely break if your host is intel
[17:30] <ogra_> :)
[17:30] <GrueMaster> You need it if you are behind a gateway.
[17:31] <persia> I don't actually seem to have /etc/resolv.conf on any of the systems in which I have an open termina.
[17:31] <ogra_> you could add a test case using qemu-static
[17:31] <GrueMaster> The bind mount won't break if you follow the instructions:  To test this image on an already running armv7 system, ...
[17:31] <persia> Ah, rather, it's not delivered.  Nevermind.
[17:31] <GrueMaster> Someone who knows how to use qemu can add that.
[17:31] <ogra_> so people can test on intel
[17:31] <ogra_> its one cp more
[17:31] <ogra_> and indeed having the package installed
[17:31] <persia> ogra_, That pollutes the rootfs ...
[17:32] <ogra_> persia, indeed it does, but it helps getting testers
[17:32] <ogra_> since its not hw bound
[17:32] <persia> I suppose.
[17:32] <GrueMaster> Getting testers is not much of a concern if we don't have any defined tests.
[17:33] <ogra_> and you get tests of qemu as a sideffect :)
[17:36] <persia> Um, I suppose.
[17:38] <persia> ogra_, I'm reminded: you might be interested in Debian bug #635385
[17:38] <ubot2> Debian bug 635385 in qemu-user-static "qemu-user-static should upgrade static libraries in qemu-debootstrap created chroots" [Minor,Open] http://bugs.debian.org/635385
[18:14] <mahmoh> davidm: did you see https://bugs.launchpad.net/linux-linaro/+bug/709245/comments/25
[18:14] <ubot2> Ubuntu bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed]
[18:20] <infinity> mahmoh: Ahh, nice.  That confirms the suspicion I had earlier today that it might be spinlock related.
[18:23] <GrueMaster> Would be interesting if someone could reproduce this on a non-omap4 Coretex-A9 system.
[18:23] <infinity> They can.
[18:24] <infinity> In fact, every report we've had of it seems to be dual core A9s, hence the earlier suspicions about SMP spinlocks.
[18:24] <GrueMaster> So, is it the SMP code, or deeper (say Cortex-A9 core).
[18:24] <infinity> Well, that combined with the timing revelation.
[18:24] <mahmoh> infinity: so how can we cap the spinlock easily without nosmp?
[18:24] <infinity> mahmoh: We need to trace the actual bug in play here.
[18:24] <GrueMaster> Isn't there a different scheduler in the kernel that we could try?
[18:24] <infinity> mahmoh: This isn't something we want to work around, this needs fixing.  Broken SMP is, uhm.  Bad.
[18:25] <mahmoh> infinity: so besides nosmp, there's not easy way without starting tracing?
[18:25] <infinity> mahmoh: nosmp ends up making every spinlock a no-op.
[18:25] <mahmoh> infinity: yeah, I',m not suggesting w-o, suggesting narrowing the problem and validating
[18:26] <infinity> mahmoh: There are people at both Linaro and RedHat working on this.  Now that we're off the wrong "looks like a USB issue" track and onto a spinlock witch hunt, I suspect it'll go well.
[18:26] <mahmoh> infinity: fair enough
[18:27] <infinity> The SMP scheduler is actually pretty well-audited and sane code.  So, if some naive ARM commiter broke it, it should jump out at someone.
[18:39] <prpplague> GrueMaster: i haven't performed the tests myself, but i have been told from several sources that it has been replicated on the Snowball and tegra2 platforms
[18:41] <GrueMaster> prpplague: So I've heard.  My only question is if it is indeed kernel SMP code or possibly Cortex-A9 design flaw.  I have seen similar issues with SMP and bus timing eons ago on the P6 (circa 1996).
[18:41] <prpplague> GrueMaster: indeed
[18:41] <GrueMaster> Unfortunately, I don't have the means to test at that level.
[18:43] <GrueMaster> And it wouldn't be the first time we have seen a hw bug expressed in code.
[18:50] <prpplague> GrueMaster: i'm sending an internal TI email now
[18:51] <GrueMaster> ok
[19:09] <prpplague> GrueMaster: i've got some time scheduled with the hardcore smp guys tomorrow afternoon to do some debugging
[19:10] <GrueMaster>  Cool.
[19:19] <martyn> GrueMaster: I just walked in on the conversaton -- what's going on with SMP on Cortex A9?
[19:20] <martyn> I have multiple non-OMAP systems here.  (Versatile express, tegra2, Calxeda, STMicro )
[19:26] <GrueMaster> martyn: See bug 709245  Especially later comments.
[19:26] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
[19:27] <martyn> AHHHhh.. we're also seeing slow IO
[19:27] <martyn> in SATA
[19:27] <martyn> (and other tests)
[19:27] <martyn> sometimes -very- slow
[19:54] <robher> I don't think nosmp affects the spinlock code itself. On x86, I believe spinlock code is patched at boot time for UP vs. SMP.
[19:55] <robher> But on ARM, there is no run-time patching of spinlocks. Only virt_to_phys is patched.
[20:34] <prpplague> martyn: i have a test shell script
[20:34] <prpplague> martyn: you just need a usb hd to test with
[20:35] <prpplague> martyn: which platform?
[20:35] <prpplague> GrueMaster: interesting enough, i just did some tests on two x86 machines. the transfer rates from the usb hd increase while pinging localhost
[20:36] <GrueMaster> Hrm.  That's not right.
[20:37] <prpplague> GrueMaster: http://pastebin.pandaboard.org/index.php/view/52887671
[20:38] <prpplague> GrueMaster: mostly on the low end size
[20:38] <prpplague> GrueMaster: smp - http://pastebin.pandaboard.org/index.php/view/3241419
[20:39] <GrueMaster> Did you run one of the tests from TheSeven?
[20:39] <prpplague> GrueMaster: no smp - http://pastebin.pandaboard.org/index.php/view/2138338
[20:39] <GrueMaster> Whoa!!  Same board?  UP vs SMP?
[20:40] <prpplague> GrueMaster: based on TheSeven 's stuff
[20:41] <GrueMaster> I'll try to reproduce that here once I get a spare minute.  I have a spare Core2Duo that is currently acting as a dust collector.
[20:49] <TheSeven> prpplague: so these pastes are x86 data?
[20:50] <TheSeven> hm, if the first one is x86 and the other two ones pandaboard it makes sense
[20:51] <TheSeven> and i'd call that increase on x86 with ping a fluke... it's way smaller than the fluctuations between the repeated measurements
[20:55] <martyn> prpplague : Okay, back at terminal
[20:55] <TheSeven> prpplague: my shell script has a small bug btw, you need to kill the perl background tasks with SIGTERM, not SIGINT, or they won't go away
[20:55] <martyn> hit me with the script
[20:55] <martyn> I can try it on a VExpress
[20:57] <TheSeven> http://paste.ubuntu.com/657485/
[20:57] <TheSeven> run that as root and pass some storage device node as the only argument
[20:57] <TheSeven> sudo ./speedtest.sh /dev/sda is what I'm running on my board
[21:03] <martyn> ah, I"ll have to install perl
[21:03] <TheSeven> you can probably skip the perl tests
[21:04] <TheSeven> the nothing vs. ping difference is the biggest one
[21:04] <TheSeven> the various perl commands are somewhere in between
[21:07] <GrueMaster> And the perl tests could fairly easily be converted to bash scripts (esp the while loop).
[21:07] <TheSeven> i used perl to get rid of possible process invocations that could affect the threading behavior in non-obvious ways
[21:08] <martyn> okay, the machines in the lab are in use for a test, I'll run the script as soon as I can get access
[21:16] <davidm> mahmoh, yes saw that comment
[21:17] <GrueMaster> davidm: It may possibly extend beyond arm.  More testing is being done.  See scrollback.
[21:19] <davidm> GrueMaster, I'm reading the scroll back now.
[21:21] <davidm> GrueMaster, in any case, it's becoming clear it's not USB, the symptoms are just easiest to see there
[21:24] <GrueMaster> yes.
[21:25] <TheSeven> the same thing happens to a lesser degree for SD card access on the pandaboard as well
[21:25] <prpplague> TheSeven: i yanked the perl stuff from the script
[21:26] <prpplague> hehe martyn quites about the time i get back to my console


[01:04] -queuebot:#ubuntu-release- New binary: qgis [amd64] (lunar-proposed/universe) [3.22.13+dfsg-1] (no packageset)
[01:10] -queuebot:#ubuntu-release- New binary: qgis [ppc64el] (lunar-proposed/universe) [3.22.13+dfsg-1] (no packageset)
[01:23] -queuebot:#ubuntu-release- New source: patchance (lunar-proposed/primary) [0.2.0-0ubuntu1]
[02:19] -queuebot:#ubuntu-release- Unapproved: munin (focal-proposed/universe) [2.0.56-1ubuntu1 => 2.0.56-1ubuntu1.1] (no packageset)
[02:19] -queuebot:#ubuntu-release- Unapproved: munin (kinetic-proposed/universe) [2.0.69-1ubuntu1 => 2.0.69-1ubuntu1.1] (no packageset)
[02:19] -queuebot:#ubuntu-release- Unapproved: munin (jammy-proposed/universe) [2.0.57-1ubuntu2 => 2.0.57-1ubuntu2.1] (no packageset)
[05:30] -queuebot:#ubuntu-release- New binary: libpinyin [amd64] (lunar-proposed/main) [2.7.92-2] (input-methods, ubuntu-desktop)
[05:31] -queuebot:#ubuntu-release- New binary: libpinyin [ppc64el] (lunar-proposed/main) [2.7.92-2] (input-methods, ubuntu-desktop)
[05:31] -queuebot:#ubuntu-release- New binary: libpinyin [s390x] (lunar-proposed/main) [2.7.92-2] (input-methods, ubuntu-desktop)
[05:34] -queuebot:#ubuntu-release- New binary: libpinyin [armhf] (lunar-proposed/main) [2.7.92-2] (input-methods, ubuntu-desktop)
[05:36] -queuebot:#ubuntu-release- New binary: libpinyin [arm64] (lunar-proposed/main) [2.7.92-2] (input-methods, ubuntu-desktop)
[06:10] -queuebot:#ubuntu-release- New binary: qgis [armhf] (lunar-proposed/universe) [3.22.13+dfsg-1] (no packageset)
[06:16] -queuebot:#ubuntu-release- New binary: libpinyin [riscv64] (lunar-proposed/main) [2.7.92-2] (input-methods, ubuntu-desktop)
[07:24] -queuebot:#ubuntu-release- New binary: qgis [arm64] (lunar-proposed/universe) [3.22.13+dfsg-1] (no packageset)
[08:14] <LocutusOfBorg> jbicha, what? at-spi2-core is something I don't know...
[08:17] <RikMills> LocutusOfBorg: source package for libatk-bridge2.0-0 in lunra
[08:18] <RikMills> or lunar even!
[08:21] <LocutusOfBorg> RikMills, and why should I open a defect, where is the defect?
[08:21] <LocutusOfBorg> I'm lost...
[08:21] <LocutusOfBorg> is it related to the dbus uninstallable issue=
[08:21] <LocutusOfBorg> ?
[08:22] <RikMills> It is
[08:22] <RikMills> and yes, I think that source is not at fault. it is the debus thing
[08:22] <RikMills> *dbus
[08:24] <LocutusOfBorg> jbicha, LP: #1997338
[08:24] <RikMills> looking at some of those tests that fail on dbus, the initial testbed-packages list seems to include dbus packages from the dbus in proposed, which can't surely be correct?
[08:24] -ubottu:#ubuntu-release- Launchpad bug 1997338 in at-spi2-core (Ubuntu) "libatk-bridge2.0-0 uninstallable on i386" [Undecided, New] https://launchpad.net/bugs/1997338
[08:25] <RikMills> the testbed should surely be all release pocket
[08:25] <RikMills> and only things in proposed installed by test deps after if required
[08:28] <LocutusOfBorg><EMAIL_ADDRESS>[08:30] <cpaelzer> I know there has been a lot of test queue delay recently, but one question on that topic. I've seen things I track to go to "No test result". That part is kind of ok as I'm convinced it will work, but does that mean we let things pass without a test result or would I need to re-run those?
[08:30] <LocutusOfBorg><EMAIL_ADDRESS>[08:30] <LocutusOfBorg> RikMills, ^^ this one shouldn't have proposed enabled
[08:31] <cpaelzer> Forget what I said 2 minutes ago, some analysis shows that this is special to this particular test which on infratsurture gos into "neutral" state. So it is ok.
[08:34] <RikMills> LocutusOfBorg: and yet the artifacts for that run show that dbus from proposed is installed in the testbed before the actual test deps are resolved
[08:35] <RikMills><EMAIL_ADDRESS>[08:35] <RikMills> dbus-bin	1.14.0-2ubuntu3
[08:35] <RikMills> dbus-daemon	1.14.0-2ubuntu3
[08:35] <RikMills> dbus-session-bus-common	1.14.0-2ubuntu3
[08:35] <RikMills> dbus-system-bus-common	1.14.0-2ubuntu3
[08:35] <RikMills> dbus-user-session	1.14.0-2ubuntu3
[08:39] <LocutusOfBorg> RikMills, what is the problem of dbus-proposed?
[08:41] <RikMills> that log is not very clear on that
[08:42] <RikMills> apt as useful not giving helpful output
[08:42] <RikMills> *usual
[09:04] <LocutusOfBorg> RikMills, sadly, I cant reproduce on local pbuilder environment
[09:14] <RikMills> LocutusOfBorg: same here the other day. think it is specific to the testbeds in the runners
[09:19] <LocutusOfBorg> jbicha, for pkgconf delta, I don't know if this still applies or not
[09:20] <LocutusOfBorg> xnox, ^^ is this pkgconfig crosswrapper still useful with newer pkgconf?
[10:47] <LocutusOfBorg> vorlon, kodi-inputstream-adaptive? its blocking kodi, needs a sync or a rebuild, don't know...
[11:49] <LocutusOfBorg> xnox, jbicha, from what I can see, pkgconfig delta was about adding this:  PKG_CONFIG_LIBDIR="$PKG_CONFIG_LIBDIR:/usr/lib/pkgconfig"
[11:50] <LocutusOfBorg> now pkgconf switch to personalities
[11:50] <LocutusOfBorg> +DefaultSearchPaths: /usr/local/lib/@MULTIARCH@/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/@MULTIARCH@/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
[11:50] <LocutusOfBorg> so, the search path is already including it.
[12:18] -queuebot:#ubuntu-release- Unapproved: libqmi (kinetic-proposed/main) [1.31~git20220823-0ubuntu2 => 1.32.0-1ubuntu<IP_ADDRESS>] (desktop-core, i386-whitelist)
[12:27] -queuebot:#ubuntu-release- New: accepted libpinyin [amd64] (lunar-proposed) [2.7.92-2]
[12:27] -queuebot:#ubuntu-release- New: accepted libpinyin [armhf] (lunar-proposed) [2.7.92-2]
[12:27] -queuebot:#ubuntu-release- New: accepted libpinyin [riscv64] (lunar-proposed) [2.7.92-2]
[12:27] -queuebot:#ubuntu-release- New: accepted libpinyin [arm64] (lunar-proposed) [2.7.92-2]
[12:27] -queuebot:#ubuntu-release- New: accepted libpinyin [s390x] (lunar-proposed) [2.7.92-2]
[12:27] -queuebot:#ubuntu-release- New: accepted libpinyin [ppc64el] (lunar-proposed) [2.7.92-2]
[12:35] -queuebot:#ubuntu-release- Unapproved: libmbim (kinetic-proposed/main) [1.27~git20220823-0ubuntu1 => 1.28.0-1~ubuntu22.10.1] (desktop-core, i386-whitelist)
[12:46] -queuebot:#ubuntu-release- Unapproved: modemmanager (kinetic-proposed/main) [1.19~git20220905-0ubuntu2 => 1.20.0-1~ubuntu22.10.1] (desktop-core, i386-whitelist)
[12:58] <icey[m]> hey - any chance the Ceph update in focal-proposed could be accepted into -updates??
[13:02] -queuebot:#ubuntu-release- Unapproved: librest (kinetic-proposed/main) [0.9.1-2 => 0.9.1-2ubuntu1] (i386-whitelist, ubuntu-desktop)
[13:14] -queuebot:#ubuntu-release- Unapproved: snapd (kinetic-proposed/main) [2.57.5+22.10 => 2.57.5+22.10] (desktop-core, ubuntu-server) (sync)
[13:14] <xnox> LocutusOfBorg:  i have no idea, i last touched pkgconfig years ago
[13:15] <xnox> ubuntu-sru / ubuntu-archive team the above snapd binary copy is interesting. riscv64 build in kinetic-proposed failed, but suceeded in lunar-proposed (better builder), and it is abi compatible with kinetic. Thus requesting binary copy from lunar to kinetic-proposed, to bring riscv64 binary back to kinetic-proposed.
[13:15] <xnox> as otherwise retries in kinetic-proposed fail to upload on riscv64 as "this binary already exists in this immutable archive"
[13:17] <xnox> cc: @cjwatson ^^^
[14:35] -queuebot:#ubuntu-release- New binary: py-rnp [amd64] (lunar-proposed/universe) [0.1.0+git20221014.01b7129-4] (no packageset)
[14:45] -queuebot:#ubuntu-release- Unapproved: flash-kernel (jammy-proposed/main) [3.104ubuntu14 => 3.104ubuntu14.1] (core)
[15:07] <bdmurray> Could an AA copy dbus from lunar-proposed to lunar? The version in kinetic-updates is greater than the version in lunar, its a security update, the three autopkgtest failures (so far) seem spurious and its causing other issues in the autopkgtest environment.
[15:11] -queuebot:#ubuntu-release- New: accepted py-rnp [amd64] (lunar-proposed) [0.1.0+git20221014.01b7129-4]
[15:11] -queuebot:#ubuntu-release- New: accepted qgis [arm64] (lunar-proposed) [3.22.13+dfsg-1]
[15:12] -queuebot:#ubuntu-release- New: accepted golang-github-keybase-go-ps [amd64] (lunar-proposed) [0.0~git20190827.91aafc9-1]
[15:12] -queuebot:#ubuntu-release- New: accepted qgis [armhf] (lunar-proposed) [3.22.13+dfsg-1]
[15:12] -queuebot:#ubuntu-release- New: accepted qgis [amd64] (lunar-proposed) [3.22.13+dfsg-1]
[15:12] -queuebot:#ubuntu-release- New: accepted qgis [ppc64el] (lunar-proposed) [3.22.13+dfsg-1]
[15:25] <bdmurray> Additionally a bunch of the tests listed in progress in the update_excuses report are lies
[15:38] <LocutusOfBorg> bdmurray, ^^ yes please this might fix the issues we are facing :)
[15:39] <LocutusOfBorg> sadly also curl needs to migrate to fix some other installability I guess
[16:13] -queuebot:#ubuntu-release- New sync: postgresql-15 (lunar-proposed/primary) [15.1-1]
[18:22] <bdmurray> FTR dbus has moved to release pocket for lunar
[18:24] -queuebot:#ubuntu-release- Unapproved: masakari-monitors (focal-proposed/main) [9.0.0-0ubuntu<IP_ADDRESS> => 9.0.0-0ubuntu<IP_ADDRESS>] (no packageset)
[21:29] <vorlon> LocutusOfBorg: kodi> I also don't know, and I'm off this week for Thanksgiving so have limited time to look
[21:30] <vorlon> xnox: by policy we should not copy it back from lunar to kinetic as this risks ABI skew.  Fresh uploads to each series probably better here
[23:30] -queuebot:#ubuntu-release- New binary: golang-github-iguanesolutions-go-systemd [amd64] (lunar-proposed/none) [5.1.0-1] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: golang-github-influxdata-influxdb1-client [amd64] (lunar-proposed/none) [0.0~git20220302.a9ab567-1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: h5z-zfp [riscv64] (lunar-proposed/none) [1.1.0+git20221021-1] (no packageset)
[23:57] -queuebot:#ubuntu-release- New binary: h5z-zfp [armhf] (lunar-proposed/universe) [1.1.0+git20221021-1] (no packageset)


[17:27] <Robdgreat> O.o
[18:38] <r2d2rogers> that is odd
[18:38] <r2d2rogers> AHHH
[18:39] <r2d2rogers> new bot due to stuff talked about at USD I'd reckon
[18:39] <r2d2rogers> haven't read the posts yet
[18:39] <r2d2rogers> there was a minor uproar I think