[08:25] <caribou> Hello, Any reason why many of the Jammy kernels have disapeared from the archives ?
[08:25] <caribou> For instance :
[08:25] <caribou> # apt-get install --allow-downgrades linux-image-5.15.0-52-generic
[08:25] <caribou> Reading package lists... Done
[08:25] <caribou> Building dependency tree... Done
[08:25] <caribou> Reading state information... Done
[08:25] <caribou> Package linux-image-5.15.0-52-generic is not available, but is referred to by another package.
[08:25] <caribou> This may mean that the package is missing, has been obsoleted, or
[08:26] <caribou> is only available from another source
[08:26] <caribou> E: Package 'linux-image-5.15.0-52-generic' has no installation candidate
[08:26] <caribou> its LP link also goes 404 : https://packages.ubuntu.com/jammy/linux-image-5.15.0-52-generic
[10:49] <danilogondolfo> found the same issue today with our github workflow where we try to install linux-modules-extra matching the kernel version running in the system: E: Unable to locate package linux-modules-extra-5.15.0-1036-azure
[12:30] <Jeremy31> danilogondolfo: Are you have hardware issues?
[14:16] <danilogondolfo> Jeremy31, no... it's happening in a cloud image. The package is not in the indexes anymore I guess
[14:18]  * cking waves
[14:19]  * cking wonders if any folk in the kernel team are debian developers...
[14:21] <Jeremy31> danilogondolfo: update package lists, I don't see 1036 but there is 1037
[14:22] <ogra> cking, xnox is i think ...
[14:22] <cking> if any DD can be an advocate for me, I'm making a DD application and I'd appreciate that sooo much :-) https://nm.debian.org/process/1185/
[14:22] <ogra> (and with that level of growth the last months i'd be surprised if there were not more)
[14:23] <cking> xnox, ^
[14:24] <cking> i'm hoping to get more low-level Intel + kernel related tools into Debian :-)
[14:38] <arighi> cking, +1 on that (even if I'm not a DD) :D
[14:39] <cking> arighi, i see you have asked for a package to be sponsor'd into Debian, you should become a DM :-)
[14:39] <cking> I'd +1 for that
[14:40] <arighi> cking, one thing at a time... and thanks! :)
[14:47] <cking> i love the fact that this channel's topic is "Jammy 22.04 kernel development" - lol
[14:50] <arighi> cking, it's still kernel development... :D but we should definitely update it to a more generic topic (no release dependent), not sure who has the right permissions to do that
[14:50] <cking> probably apw ;-)
[16:07] <JanC> apw, Ubuntu IRC Council & Libera staff apparently
[17:17] <ghavil> Howdy, just wanted to check in on https://packages.ubuntu.com/jammy-updates/linux-gcp-lts-22.04 getting released w/ kernel 5.15. With https://packages.ubuntu.com/jammy-updates/linux-gcp being on 5.19 now, it'd be nice to be able to run 5.15 w/ security updates.
[21:24] <chiluk> Hey folks dumb question... what is the idea behind release versioning the linux*-tools* packages... this causes lots of pain when attempting to build containers that need perf, but not knowing the kernel that will be used at runtime.
[21:25] <chiluk> afaik the tools binaries shouldn't be changing all that much within a kernel major.minor version... i.e. 5.15.0-*
[21:26] <chiluk> basically I'd like to install the latest 5.19 -tools package into my container, knowing that my runtime kernel will likely be a later release version of the same Major.minor version.
[21:38] <chiluk> As it stands now, we execute /usr/bin/perf and it bombs out because the kernel doesn't match exactly.  A better behavior would be an error for an interactive user session followed by an attempt to find the closest versioned binary, or for non-interactive simply attempt to use the closest versioned one.
[21:39] <chiluk> but that suggestion has other criticisms.
[21:50] <JanC> I assume perf & tools like that are too closely tied to the kernel build to make them work with other kernels...?
[21:53] <chiluk> JanC that is the excuse we've historically used.... in reality they are mostly compatible ..
[21:54] <JanC> I assume this is an upstream decision, no?
[22:14] <chiluk> I think this is an Ubuntu decision.
[22:15] <chiluk> It's for the same reason Ubuntu bumps the ABI on each release version... it's not strictly known if it's necessary, but it's being done out of an abundance of caution.
[22:15] <chiluk> until now I didn't have a great reason to stop doing that.
[22:16] <chiluk> i think being able to run perf out of a container may be that reason.


[02:07] <teward> Should I be highly concerned that almost all of the arm64 and armhf builders are marked as Disabled in the build farm?
[02:07] <teward> (12+ hours each for arm64 and armhf PPA queues, hence my asking...)
[02:08] <wgrant> We're working on an issue with one of our build clouds.
[02:08] <wgrant> Hopefully will be resolved soon.
[02:10] <teward> wgrant: didn't expect anyone to be alive this evening heh.  Thanks for the heads up.
[02:10] <teward> when I saw all that red, I was like "WOAH, Something blew up!" xD
[02:11] <wgrant> teward: Some of us are in Australia :)
[02:11] <teward> wgrant: ahhhhh, that explains things.  :P
[02:12] <teward> wgrant: I'm still awake because I'm busy trying to get Postfix working/patched, to get the SRU-pending patch into a Postfix build so I can mess around with it in a container, but eh.  I'm less concerned about arm64 and armhf as my arch is amd64, but meh.
[02:59] <wgrant> teward: All fixed.
[03:03] <tsimonq2> I was wondering about that too...
[03:03] <tsimonq2> Thanks a bunch wgrant!
[10:33] <rbasak> cjwatson: around? nacc and I have been talking about the plan to get things moving on Launchpad wrt. bug 1661600. We think we'd like to break the dependency loop by pointing the "official" branches to our imported repositories now. Do you have an opinion on this plan please? How much work would it be to do that?
[10:34] <rbasak> We'd announce to ubuntu-devel@ (or u-d-a, whichever is appropriate) that the branches are experimental and will be non-fast-forwarding (the hashes will change), but figure that as they're nothing there today (for git) it's the least worst option.
[10:35] <cjwatson> rbasak: I'm 1.5 days from going on holiday for two weeks, won't be available to help with that for some time
[10:35] <rbasak> Then we'd like to 1) widely accept and encourage automatic import whitelist additions from developers, and 2) with your permission, start ramping up to importing all packages.
[10:36] <rbasak> cjwatson: OK, no problem. Does this plan seem reasonable though?
[10:37] <cjwatson> it's not ideal but I guess it's not terrible and maybe there isn't a better option
[10:38] <rbasak> OK, thanks. Enjoy your holiday, and I'll ping you after you're back.
[10:38] <cjwatson> Maybe wgrant can help
[10:38] <cjwatson> What's the "automatic import whitelist"?
[10:39] <rbasak> We're automatically importing a (small) subset of packages at the moment, from a whitelist.
[10:39] <cjwatson> Ah right
[10:39] <cjwatson> Also do you not need per-ref ACLs before you go very much further?
[10:40] <cjwatson> rbasak: re "how much work", the answer is "some" - LP's going to need a few gaps filled in, mostly to grant some suitable permissions to some entity to set default repositories for packages
[10:40] <rbasak> If the "official" branches just symlink to our current trees, then we figured out a plan to do without them for a long time yet (we don't need them for 1.0). We'll be relying only on the fact that the set of people who can push to the repositories at all is ~usd-import-team.
[10:41] <rbasak> And the importer will take care of the rest, as the only pusher.
[10:41] <cjwatson> symlink isn't quite a thing but I know what you mean
[10:41] <rbasak> It'll harvest rich history from MPs.
[10:41] <rbasak> Yeah I should've said symlink* :)
[10:42] <cjwatson> let's say alias
[10:42] <rbasak> OK
[10:42] <cjwatson> another thing we might need to do is check for sufficient hosting space; we have a bit over a terabyte free on the relevant volume at the moment
[10:43] <cjwatson> which is hopefully fine but it'd be nice to not blow through it all at once :)
[10:43] <rbasak> Yeah we thought you might. We can manage a ramp up independently of setting up the aliases though, right?
[10:43] <cjwatson> indeed
[10:43] <rbasak> I don't have a good grasp of how much space we need. git is efficient, but as we're importing all history that still might be quite a bit.
[10:43] <cjwatson> it'd be package by package
[10:44] <rbasak> Right, so approximately the total size of the sources in the archive plus deduplicated history of those sources.
[10:44] <rbasak> (plus all sources that have been deleted and are no longer present in artful)
[10:44] <cjwatson> lp.git_repositories.setDefaultRepository(repository=foo, target='/ubuntu/+source/foo') basically, once that works
[10:46] <cjwatson> so the ramp-up would probably just be by way of setting up aliases as packages are imported
[10:46] <rbasak> You want us to do that one by one, rather than having some kind of global "all of /ubuntu/+source/* is at /~foo/.../*"?
[10:47] <cjwatson> Yes.
[10:47] <rbasak> OK, np. It'd be trivial for us to have the importer make the API call. I just wasn't expecting it.
[10:48] <rbasak> Or perhaps we should make the call manually as we ramp up. Either way, it is trivial.
[10:48] <cjwatson> Whether a repository is the default for its target is a flag on the repository
[10:48] <cjwatson> In database terms
[10:48] <rbasak> OK
[10:48] <cjwatson> So it couldn't be done as a pattern-match without significant reworking
[15:12] <nacc> rbasak: want to file a bug (or add a task for the importer if there is already a lp bug for the above)?
[15:41] <teward> wgrant: thanks.
[15:41] <teward> (sorry, slow reply)


[10:58] <Luciferus-UCS> Hello all! Anybody using separate X screen nvidia configuration in new OS with Mate Enviropment?
[10:59] <Luciferus-UCS> And have a problems with it?
[11:10] <Luciferus-UCS> Does anyone understand at all what I'm talking about here?


[01:29] <anrebs> hey I have a problem with a pc of mine connecting to the internet. wifi is working fine and my laptop connects fine but since I updated the system to my pc the network stopped working. I've tried several methods and they don't work. I tried restarting network manager and connecting through eth0 but my pc doesn't have the option of going eth0.
[02:36] <longerstaff13> sounds like you need to check for driver updated
[02:36] <longerstaff13> updates*
[02:37] <longerstaff13> anrebs: ^
[12:27] <adarshcr7> hello
[12:27] <adarshcr7> can anyone tell me till when lubuntu is 16 is supported
[12:28] <adarshcr7> i want to install lubuntu 16 in my pc
[12:29] <hateball> adarshcr7: 16.04 is supported for 5 years
[12:29] <hateball> !lts
[12:29] <adarshcr7> okay which should i install 64bit or 32bit
[12:29] <adarshcr7> ???
[12:33] <adarshcr7> my system configuration : Intel(R)Core(TM)2Duo<EMAIL_ADDRESS>[12:34] <adarshcr7> hello
[12:34] <hateball> adarshcr7: I would say 64bit, 32-bit is going away
[12:34] <hateball> well not away, but 64bit will be prioritized
[12:34] <hateball> adarshcr7: If you can, I'd suggest upgrading RAM to 4GB
[12:35] <adarshcr7> okay
[12:35] <adarshcr7> how about lubuntu 12 64bit
[12:36] <adarshcr7> is it okay to install
[12:36] <daffodil> why not install the most current version?
[12:36] <adarshcr7> cause upgrading is not possible
[12:36] <daffodil> i have lubuntu going on a netbook that only has a gig of ram
[12:37] <adarshcr7> can you provide me link to download
[12:38] <daffodil> lubuntu.net
[12:38] <adarshcr7> thank you
[14:48] <jeyty> When will lubuntu 16.04.2 be released?
[14:48] <leszek> you mean a new ISO ?
[14:54] <jeyty> yes
[14:56] <leszek> not sure.
[14:57] <leszek> jeyty: they are already available as it seems but the links aren't updated yet. So grab your ISO from here: http://cdimage.ubuntu.com/lubuntu/releases/xenial/release/
[17:05] <CocoLubuntu> Is it possible to install Snap apps in Lubuntu 16.04.2 (amd64) ?
[22:54] <anrebs> how do I update my driver without internet?


[10:28] <aholler> hello, having read about the problem to build 20,000 packages for arm and the panda-cluster, I wonder if the ubuntu-devs ever tried or even heard about icecream? http://en.opensuse.org/Icecream
[10:30] <ogra_> yes
[10:31] <GrueMaster> aholler: Distribuited buildshave not been the issue.  The issue has been lack of hardware for native builds.
[10:31] <aholler> using icecream you could use every x86 box
[10:32] <aholler> to help you build your packages
[10:32] <GrueMaster> How can anx86 build arm "native" packages?
[10:32] <aholler> read about how icecream works
[10:32] <GrueMaster> Not cross-compiled. Native.
[10:32] <aholler> sure
[10:33] <GrueMaster> x86 does not run arm instructions w/o emulation.
[10:33] <aholler> read about how icecream works
[10:34] <aholler> ogra_: do you have tried it?
[10:34] <GrueMaster> After a quick glance, again I ask how this would have helped the lack of arm hardware issue we faced prior to our panda cluster?
[10:35] <GrueMaster> btw:  I have worked on distribuited build environments before.
[10:35] <ogra_> package builds are usually single threaded, that doesnt gain you much with most packages
[10:35] <aholler> GrueMaster: you could use e.g. make -j20 and the compilation would be done by the x86-boxes
[10:36] <aholler> but the tests would be done localy = native
[10:36] <GrueMaster> Listen to what I am saying.  how does an x86 box compile native arm code w/o cross-compiling?
[10:36]  * ppisati didn't read anything about "the problem to build 20,000 packages"
[10:37] <GrueMaster> I spent 8 years in processor validation at Intel, and now work on arm code.  The instruction sets areentirely different.
[10:37] <aholler> GrueMaster: again, read about how icecream works.
[10:37] <aholler> nothing on your arm-box will see the difference
[10:37] <aholler> there is cross-compiling and cross-compiling
[10:37] <ogra_> the binaries will be built with a cross toolchain ...
[10:37] <ogra_> thats the difference
[10:38] <aholler> just the objects
[10:38] <ogra_> you cant guarantee that you get identical binaries with a cross toolchain
[10:38] <GrueMaster> We build all binary packages on their native hardware.  We do not rely on cross-compilation.
[10:38] <aholler> GrueMaster: I assume you haven't understand how icecream works. anyway, I'm off, I don't see why I should try to continue this discussion
[10:39] <GrueMaster> I know how icecream works.  I have talked with some of the devs when they started building it.
[10:40] <ogra_> iirc NCommand1r used it across 4 babbages for OOo builds
[10:40] <GrueMaster> No, he used distcc.
[10:40] <ogra_> hmm, i thought it was icecream
[10:40] <hrw> I love this kind of talks
[10:40] <ogra_> hrw, you could have chimed in :)
[10:41] <hrw> 'hey guys, why you are building natively? are you insane? cross compilation on farm of cheap x86 is better' etc...
[10:41] <ogra_> as compiler expert
[10:41] <suihkulokki> I guess the guy you chased away was trying suggest running the build on one arm machine which the calls icecream/distcc to x86 machines running crosscompilers
[10:41] <ogra_> suihkulokki, yes
[10:41] <ogra_> SuSE OBS ...
[10:42] <suihkulokki> OBS dodn't due that
[10:42] <ogra_> i thought they inject an x86 compiler into a native build env
[10:43] <suihkulokki> you should invite the guy back if you are really intersted in how they do instead of rejecting them on sight ;)
[10:43] <GrueMaster> I honestly don't see how ANY distributed environment would benefit anyone that needs native hardware and doesn't have it.
[10:43] <ogra_> the distributed part only helps with packages using -jN
[10:44] <GrueMaster> We could easily deploy icecream (or any other distributed build environment) on our cluster, but the issue was the lack of hardware.
[10:44] <hrw> suihkulokki: like GrueMaster said - we lack native builds and this is a problem to solve
[10:45] <hrw> xU with 120 a9 quadcores for example - I read on linuxdevices that someone is working on such beast
[10:46] <GrueMaster> yep.  That would be a nice addition to my rack cabinet at home.  :P
[10:46]  * ogra_ waits until he can buy that in a mac mini like case
[11:15] <garagoth> GrueMaster: Hi. You and rsalveti have provided patched kernel for Beagle xM rev C. Is it possible to have it patched to support i2c bus 2, which is available on expansion port/
[11:15] <garagoth> ?
[11:33] <GrueMaster> garagoth: Have to ask rsalveti.  As soon as he provides me with a binary, I'll update the tarball.
[11:39] <hrw> ogra_: btw - how much ac100 costs in .de?
[11:46] <garagoth> GrueMaster: Ok, thanks.
[11:47] <garagoth> rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ?
[11:47] <ogra_> hrw, my last one costed me 170€ off the shelf
[11:48] <hrw> 202EUR here
[11:48] <ogra_> ppisati, http://hackaday.com/2011/06/12/how-canonical-automates-linux-package-compilation/ ...
[11:48] <GrueMaster> ogra_: It was cheaper because of that funky keyboard.  :P
[11:49] <ogra_> "Canonical needed a way to compile about 20,000+ packages for the ARM platform, however they did not want to cross-compile, which is quite time consuming."
[11:49]  * ogra_ shakes his head
[11:49] <ogra_> why would cross compiling be quite time consuming
[11:49] <garagoth> on the contrary I would say...
[11:50] <ogra_> heh, yeah
[11:50] <ogra_> probably i'm reading it wrong though
[11:55] <suihkulokki> there is no ubuntu-arm mailing list?
[11:56] <hrw> bug 791302 needs someone familiar with library symbols?
[11:56] <ubot2> Launchpad bug 791302 in libechonest "libechonest version 1.1.3-1 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791302
[11:56] <hrw> suihkulokki: no, ubuntu-mobile was dropped
[11:56] <hrw> suihkulokki: ubuntu-devel is used
[11:57] <suihkulokki> I shall spam ubuntu-devel then =)
[12:01] <aholler> ok, I'll try it again.
[12:01] <aholler> To enlight the people here about waht I'm speaking, using icecream only a part of the compilation process is distributed. And there is absolutely no problem when this part is a cross-compiler/-assembler. Thats a whole difference to what people usually are thinking about cross-compiling.
[12:02] <aholler> And using icecream is much better than using distcc, because the building machine distributes the (cross-)compiler (as a chroot, once).
[12:02] <aholler> what gets distributed is a tar-archive containing that stuff: http://www.fpaste.org/PyrG/
[12:02] <hrw> aholler: does it takes care of mix of amd64/i386/armel/armhf build machines too?
[12:03] <aholler> yes, the build-machine gets informed about the architecture of the slaves and can send them the needed chroot
[12:03] <hrw> I think I will have to setup icecream farm of pandas here
[12:03] <aholler> or just don't use them
[12:03] <aholler> that even speeds up compiling using only -j1
[12:04] <ogra_> aholler, as i said above, we wouldnt get much benefit from a distributed env, the majority of the packages will default to not use -jN
[12:04] <hrw> aholler: I spent 6 years on cross compilation
[12:04] <ogra_> there are some where it really helps, i agree
[12:04] <ogra_> i.e. libO
[12:04] <aholler> hrw: fine for you
[12:05] <ogra_> or firefox ... but the majority wont really benefit from it... for us its more important to build as many *differnt packages* at the same time as possible
[12:06] <aholler> most packages could be build using -jN, at least when ext4 is used.
[12:06] <ogra_> the target of the build cluster is to empty the queue as fast as possible to keep up with the other arches, so "more paralell builds" > "faster builds"
[12:06] <aholler> with ext3 there are more problems, because of the limited timestamp
[12:07] <aholler> a single source is still compiled a lot faster on x86 (+network transfer) than on an arm
[12:07] <ogra_> it would be good to have a fully native icecream setup on another panda cluster though and route the packages that can benefit from it to that build system
[12:08] <ogra_> we definitely wouldnt use it with a cross compiler
[12:09] <GrueMaster> Actually, if icecream can manage client build systems appearing on the fly, it could easily be deployed now on our panda cluster.
[12:09] <ogra_> but the concept could indeed help with native compilers too ...
[12:09] <aholler> do you expect a different output from a cross-assembler than native?
[12:09] <ogra_> the possibility exists
[12:09] <GrueMaster> aholler: Yes, and we have actual documented bugs with that.
[12:10] <aholler> don't mix that concept icecream/distcc uses which the stuff people usually are understanding with cross-compiling
[12:10] <aholler> s/which/with/
[12:11] <aholler> anyway, it is just a suggestion, I don't need to convince the people here.
[12:12] <ogra_> well, i like the concept of distributed building ...
[12:12] <aholler> ditributed cross- is even better
[12:12] <ogra_> thats something i would not agree on :)
[12:13]  * ppisati -> out to get some food
[12:13] <aholler> I've used that a lot to build x32packages on x64-machines (and vice-versa) several years before
[12:14] <aholler> no, wrong, the other machines helped building the packes, they haven't build them
[12:14] <aholler> anyway, maybe one of you might try it. I'm off again. ;)
[12:14] <GrueMaster> we use x86_64 machines to build i386 packages all the time.  That isnt an issue.
[12:15] <ogra_> he's gone
[12:17] <hrw> hm. how to call shell in perl and get return as value of variable?
[12:19] <GrueMaster> hrw:  give me a minute and I'll pastebin a sample ofcode I wrote while at Intel.
[12:22] <hrw> $var = `command`; ;)
[12:23] <ogra_> thats as clever as using system() :P
[12:24] <hrw> with system I have to play with $? etc to get result
[12:26] <hrw> looks like gnu-smalltalk will be fixed
[12:26] <hrw> not that I know perl but fix was needed in perl script
[12:28] <GrueMaster> hrw: Looks like you have it.
[12:28] <hrw>     my $multiarch_dir = `dpkg-architecture -qDEB_HOST_MULTIARCH`;
[12:28] <hrw>     chomp($multiarch_dir);
[12:29] <hrw> and then one more check in script
[12:30] <hrw> ok. passed step where it was failing
[12:31] <hrw> now time for debdiff
[12:31] <persia> hrw, Why not "use Dpkg:Arch ..."?  That should save considerable cycles.
[12:32] <persia> (if you just care about multiarch, then "use Dpkg:Arch qw(debarch_to_multiarch);" is probably sufficient)
[12:32] <hrw> persia: because I do not know perl?
[12:33] <hrw> persia: so I am trying to get some hack which works and then it can get improved
[12:33] <persia> hrw, Heh.  So, take a look at the dpkg-architecture source.
[12:33] <persia> It's fairly trivial to just pull the value from the libary (and we have a nice code example)
[12:33] <hrw> thx
[12:34] <persia> Around line 196 is the bits you'll need, although you'll also  need the use statement near the top.
[12:36] <hrw> my $multiarch_dir = debarch_to_multiarch(get_raw_host_arch());
[12:36] <persia> That looks cleaner to me.  Does it work?
[12:36] <persia> Also, how is get_raw_host_arch() implemented?  Is this something you could also pull from the library?
[12:36] <hrw> both are from Dpkg::Arch
[12:37] <hrw> I picked code from dpkg-architecture
[12:37] <persia> Ah, heh.  That sounds ideal then, if it works :)
[12:37] <hrw> persia: build in process
[12:37] <persia> Just be sure to specify both in the use statement, so they are available.
[12:37] <hrw> did
[12:37] <persia> Perfect :)
[12:37] <hrw> persia: thanks for tips
[12:37] <persia> No problem.  Thanks for asking for help on the channel *before* you found the final solution.
[12:39] <hrw> persia: as I'm not perl programmer I prefer to make sure that my thinking is right.
[12:39] <hrw> persia: and my workflow for bugs is: make a fix and then make a fix to be a proper fix
[12:40] <persia> Makes sense.  I tend to try for a precise problem statement, then a proper fix (which is nearly the same thing, except that I tend to express the problem in English rather than code).
[12:41] <hrw> persia: first ver of fix was good but implementation was bad ;D
[12:41] <persia> Not bad, just didn't take advantage of the fact that dpkg-architecture was itself implemented in perl, with a handy library.
[12:42] <persia> Was dpkg-architecture in C, then I think your implementation would have been the least bad.
[12:42] <persia> (assuming nobody had created perl bindings for the library)
[13:08] <rsalveti> ppisati: ogra_: GrueMaster: http://comments.gmane.org/gmane.linux.redhat.fedora.arm/1266
[13:08] <rsalveti> pointed by agreen, if we want to have a better buildd this would be something to look for
[13:10] <garagoth> rsalveti: Is it possible for you to patch that patched kernel you prepared for beagle xm rev C to support i2c bus 2 (which is on expansion port) ?
[13:11] <rsalveti> garagoth: sure, sorry, just got on-line
[13:11] <rsalveti> garagoth: what exactly do you need?
[13:11] <garagoth> I have trainer board from tin can tools attached to beagle xm C and I need to use i2c which is there.
[13:12] <garagoth> It is nice as it is level translated to 5V
[13:12] <garagoth> it is i2c bus 2
[13:12] <garagoth> but on your kenel only buses 1 and 3 are visible
[13:13] <rsalveti> garagoth: oh, ok, guess it's the patch pointed by rcn-ee
[13:16] <garagoth> I hope so :-) I had no sources of your kernel, so could not test it myself.
[13:16] <GrueMaster> rsalveti: I had seen a blurb on the pandaboard mailing list regarding usb drive speed & networkiing.  When I get home I mean to do some additional testing, including using a usb-nic (not the on-board nic) to see if that makes a difference.
[13:17] <rsalveti> garagoth: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary if you get the HEAD you'll get the same working kernel
[13:17] <rsalveti> 10.44
[13:18] <rsalveti> garagoth: if you build this kernel and add the patch https://github.com/RobertCNelson/stable-kernel/blob/master/patches/sakoman/2.6.39/0032-OMAP3-beagle-add-support-for-expansionboards.patch it may work
[13:18] <rsalveti> didn't check if you need any other dependencies
[13:19] <garagoth> rsalveti: So, build it myself or will you be doing it anyway?
[13:20] <rsalveti> garagoth: I can guide you if you want, then you can hack it later if needed ;-)
[13:20] <ogra_> rsalveti, what exactly do you suggest ? rinning a ping daemon ?
[13:20] <ogra_> *running
[13:20] <rsalveti> ogra_: well, agreen is investigating the kernel to see if we can get a fix
[13:20] <garagoth> Would be nice. I need to setup cross-compile env for ubuntu then... somehow :-) Or compile on Beagle
[13:21] <rsalveti> but would be good to keep an eye on it
[13:22] <rsalveti> garagoth: http://www.omappedia.org/wiki/Ubuntu_kernel_build_alternatives
[13:24] <garagoth> rsalveti: Ok, processing...
[13:26] <garagoth> I guess you are cross-compiling?
[13:27] <ppisati> rsalveti: weird
[13:28] <rsalveti> garagoth: yes
[13:28] <rsalveti> ppisati: why? same chip for both usb and eth :-)
[13:30] <persia> I like the FIFO queue not overflowing answer.  It's more plausible than most of the other proposed "why"s.
[13:33] <ogra_> well, the ignore_oc stuff seems like a red herring to me
[13:35] <persia> I'd say so.
[13:35] <persia> But that's different than the queue management.
[13:41] <zumbi_> persia: can i have unity on pandaboard?
[13:41] <zumbi_> (on natty I mean)
[13:42] <persia> zumbi_, You can have unity-2d.  I don't believe everything was ported to work properly with the GLES drivers TI provided.
[13:42] <persia> (someone please correct me if I'm wrong).
[13:42] <zumbi_> so unity-3d not yet ready on arm hw :/
[13:43] <zumbi_> persia: thanks
[13:43] <ogra_> zumbi_, in th enext weeks
[13:43] <zumbi_> ogra_: sure, I guess as part of oneiric
[13:44] <ogra_> there are two bugs left afaik ... once these are solved it should be available for natty
[13:44] <ogra_> later then oneiric
[13:44] <ogra_> (all work is done on the natty branches atm and will need forward porting then)
[13:45] <persia> ogra_, This is GLES porting?
[13:45] <ogra_> yes
[13:45] <zumbi_> uhm.. ok, sounds fine, I'll try it on few weeks then
[13:45] <ogra_> for compiz, nux and unity
[13:45] <ogra_> zumbi_, rsalveti should be able to point you to a PPA for that
[13:45] <persia> zumbi_, What's your specific interest?  The interface, or reviewing the code paths?
[13:46] <ogra_> (beyond that they should show up in the natty release PPA for panda)
[13:46] <persia> If the former, then unity-2d is supposed to be mostly the same (although some things are different)
[13:46] <persia> If the latter, I'm sure folk would appreciate additional testing/help with the remaining few bugs.
[13:46] <rsalveti> zumbi_: https://launchpad.net/~rsalveti/+archive/unity-3d-gles
[13:46] <persia> ogra_, Do you happen to know the bug numbers?
[13:46] <rsalveti> zumbi_: not fully working yet
[13:46] <zumbi_> persia: right now, my interest is have a technology preview, we are currently using Qt for UI design
[13:47] <zumbi_> rsalveti: thanks
[13:47] <rsalveti> but you should be able to try it in the following days
[13:47] <ogra_> persia, for what ?
[13:47] <persia> zumbi_, unity-2d is implemented in Qt, so yeah, that doesn't necessarily show anything particularly different.
[13:47] <persia> ogra_, The compiz/nux/unity bugs.
[13:47] <ogra_> i dont think there are bugs
[13:47]  * persia grumbles
[13:48] <persia> When "there are two bugs left", those should be filed in launchpad, and discussion happen there.
[13:48] <ogra_> there is a team working fulltime on fixing them though :)
[13:48] <persia> And the team doesn't want another member, for some reason?
[13:48] <ogra_> and they report to places i am
[13:48] <ogra_> ask linaro :)
[13:48] <ogra_> i guess they wont deny if someone wants to help indeed
[13:49] <persia> rsalveti, Are there bugs?  What sort of help could speed the process?
[13:49] <rsalveti> persia: https://bugs.launchpad.net/unity-gles
[13:49] <persia> Only one left!
[13:49] <persia> zumbi_, ^^
[13:50] <ogra_> i thought there was one nux bug too
[13:50] <ogra_> but seems that got fixed already
[13:50]  * jussi prods at persia
[13:50] <rsalveti> we just discussed at the call and we may have an additional bug for nux
[13:50] <rsalveti> but still not confirmed
[13:51] <rsalveti> but it should all be sorted out during this and next week
[13:52] <ogra_> the screenshots look cool though
[13:53] <ogra_> you should leave it that way and call it unidelic instead of unity :)
[13:54] <rsalveti> ogra_: hehe :-)
[15:05] <rsalveti> and another porting jam just starting at #linaro! come and help us making ubuntu better on arm :-)
[15:05] <rsalveti> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue&orderby=-id
[15:10] <ogra_> GrueMaster, soo, your ac100 ... did you actually test if the issues also show up if you manually untar the rootfs ?
[15:11] <GrueMaster> I have put it back on the back burner.  Need to be productive on current tasks.
[15:11] <ogra_> k
[15:11] <ogra_> well, i cant do much until we have identified the actual problem
[15:12] <ogra_> make sure to definitely bring it to dublin
[15:13] <GrueMaster> I plan on it.
[15:13] <ogra_> will surely be faster to find the issue if i have direct access
[15:14] <GrueMaster> Not sure what the final goal is.  If it is just to get me enabled with an ac100, I'll do it as time allows.  If we plan on deploying a working installation for other users, it makes sense to debug it and I can add it to the test pool as time allows.
[15:15] <ogra_> well, i want the installer to work properly on all models indeed
[15:23] <ppisati> seems we are not the only one experiencing issue with usb and gcc 4.6:
[15:23] <ppisati> https://lists.yoctoproject.org/pipermail/poky/2011-April/005703.html
[15:24] <ppisati> the thread continues in may 2011 too
[15:24] <ppisati> https://lists.yoctoproject.org/pipermail/poky/2011-May/005763.html
[15:24] <garagoth> rsalveti: Ok, more or less the patch succeeded. Is git clone of the kernel source already with proper config, same as it is on beagle?
[15:27] <brendand> fully updated 11.04 running on a pandaboard, when i try to boot it i get things like
[15:27] <brendand> (stk) : line disc installation timed out
[15:27] <brendand> (stc) : KIM failure complete callback
[15:27] <GrueMaster> that is the bluetooth driver.  known issue.
[15:28] <brendand> ah - i just needed to wait long enough
[15:28] <brendand> never saw that before, is it an update-regression?
[15:29] <ppisati> and it seems there's a fix... testing...
[15:29] <GrueMaster> Yes and no.  It didn't happen in maverick as the driver was rewritten and hasn't been finalized at time of release.
[15:34] <hrw> what is a proper way to request arm rebuild of package?
[15:34] <hrw> octave-communications 1.0.10-3 was ftbfs on armel 7 weeks ago due to lack of build deps. now they are fulfilled
[15:35] <ogra_> one sec
[15:35] <hrw> I am building this package on panda now
[15:35] <hrw> it was bug 791314 btw
[15:35] <ubot2> Launchpad bug 791314 in octave-communications "octave-communications version 1.0.10-3 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/791314
[15:36] <ogra_> rebuild triggered
[15:36] <hrw> thx
[15:36] <ogra_> https://launchpad.net/ubuntu/+source/octave-communications/1.0.10-3/+build/2469824
[15:36] <hrw> I just loaded that
[15:38] <GrueMaster> ppisati: The thread continues in June as well.
[15:38] <ogra_> yeah
[15:38] <ogra_> differently named though
[15:39] <ogra_> https://lists.yoctoproject.org/pipermail/poky/2011-June/006634.html is very intresting
[15:41] <ppisati> and there's a fix
[15:41] <ppisati> wait...
[15:42] <ogra_> ppisati, https://lists.yoctoproject.org/pipermail/poky/2011-June/006646.html this one ?
[15:44] <ppisati> yep
[15:44] <ppisati> but it seems it's not working :(
[15:44] <ogra_> well, they later say you should just remove the line completely
[15:45] <ppisati> let's try...
[15:48] <ppisati> nope
[15:50] <ppisati> anyway, let me forward this info the toolchain people
[15:51] <ogra_> yeah
[15:51] <ogra_> a disassembly like that from our own binaries might help too i guess
[15:54] <ppisati> yep
[15:54] <ppisati> in the April they were saying they had this issue with the vanilla FSF 4.6 toolchain so it seems it's an upstream bug
[15:59] <ogra_> could be
[16:04] <ppisati> ok, mail sent
[16:04] <ppisati> let me update the lp bug too
[16:04] <ogra_> ++
[16:26] <garagoth> I'm trying to compile ubuntu kernel for Beagle, but process fails with error: "as: unrecognized option '-Qy'"
[16:26] <garagoth> Any hints?
[16:30] <hrw> which ubuntu?
[16:30] <hrw> and do you have binutils-arm-linux-gnueabi installed?
[16:33] <garagoth> natty
[16:33] <garagoth> and yes, I have
[16:39] <garagoth> so...?
[16:46] <garagoth> rsalveti: ping
[16:47] <melis51> hi, anyone knows the uname+pwd for ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz, thx
[16:47] <ogra_> there is none
[16:47] <ogra_> you set it up during the first boot
[16:47] <garagoth> during install you setup your user
[16:47] <melis51> this is a pre-installed image
[16:48] <garagoth> pre-installed image which install itself
[16:48] <garagoth> at least should...
[16:48] <ogra_> yes
[16:49] <garagoth> you boot it, it should show you installer
[16:49] <garagoth> you select lang, keyboard, packages, user
[16:49] <melis51> the first thing I see is a log-in screen
[16:50] <melis51> the only option is to click 'other' user
[16:50] <garagoth> on dvi port?
[16:50] <melis51> yes
[16:50] <garagoth> is it ubuntu branded?
[16:50] <melis51> yes, and this is where I downloaded from: http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz
[16:51] <GrueMaster> melis51: What platform are you using?
[16:51] <melis51> Beagleboard
[16:51] <GrueMaster> What rev?
[16:51] <melis51> c3
[16:53] <GrueMaster> Odd, although you may be running out of memory.  I don't remember an issue testing on my C4 though.
[16:54] <garagoth> on bb-xM rev C I saw setup screen on X
[16:54] <ogra_> try the headless image instaed and then install ubuntu-netbook using tasksel
[16:54] <GrueMaster> When you boot, is it pulling anything from nand, or is it booting completely off the SD?  You can tell by watching the serial console.
[16:54] <ogra_> oh, right, NAND !
[16:54]  * ogra_ totally forgot
[16:55] <GrueMaster> ogra_: That's why you keep me around. :P
[16:55] <ogra_> indeed, it might not pull the right initrd in
[16:55] <ogra_> GrueMaster, yeah, we all love you :)
[16:55] <melis51> I can't tell right now, but will check
[16:56] <lag> Do the ARM PPAs build naively?
[16:56] <ogra_> melis51, there are instructions on the wiki how to make sure to boot right
[16:56] <ogra_> lag, yes, thats why they arent public
[16:56] <lag> ogra_: All of them? Even my own PPA?
[16:57] <ogra_> only trusted people have upload permission
[16:57] <GrueMaster> melis51: Check the Maverick instructions.  They have more detail on the beagleboard w/ nand.
[16:57] <ogra_> indeed you can make the binaries public
[16:57] <melis51> ora_ I fallowed GrueMaster's instructions on the wiki that worked up until the log-in screen
[16:57] <lag> ogra_: Let me try to explain
[16:57]  * GrueMaster updates the instructions for natty.
[16:58] <melis51> ok I will try Maverick, but would be nice to get the latest ver to work too
[16:59] <ogra_> you dont need to try maverick
[16:59] <ogra_> only the maverick instructions for booting begales with NAND on them
[16:59] <melis51> ok
[16:59] <garagoth> Maybe someone can help me with cross-compiling to beagle on natty? I have "as: unrecognized option '-Qy'"
[17:00] <ogra_> garagoth, well, hrw is your best option ... beyond that, file a bug against the cross toolchain
[17:01] <GrueMaster> melis51: You can use natty, just follow the maverick instructions specific to the beagleboard rev C.
[17:01] <GrueMaster> Natty Instructions updated to include these now.
[17:01] <hrw> garagoth: fill a bug with exact info what you are doing ok?
[17:01] <melis51> ok thanks I'll try
[17:01] <garagoth> hrw: ubuntu-bug or ..?
[17:02] <hrw> garagoth: ubuntu-bug armel-cross-toolchain-base
[17:02] <hrw> garagoth: add "arm-linux-gnueabi-gcc --version" into bug raport
[17:03] <garagoth> Ok.
[17:03] <lag> ogra_: http://ppa.launchpad.net/linaro-landing-team-ste/st-ericsson-u8500-public/ubuntu/pool/main/l/linux-u8500/
[17:04] <lag> Would that have been build natively
[17:04] <ogra_> lag, yes
[17:04] <lag> ogra_: Great, thanks!
[17:04] <ogra_> we dont so any non native builds in the datacenter
[17:04] <melis51> thanks everyone for your help!
[17:04] <ogra_> s/so/do/
[17:05] <garagoth> hrw: it says: no such package: armel-cross-toolchain-base
[17:05] <GrueMaster> melis51: got it working?
[17:06] <hrw> garagoth: so use binutils-arm-linux-gnueabi one
[17:06] <hrw> garagoth: armel-cross-toolchain-base is source package
[17:07] <melis51> I'm not at home, so I will try it a bit later today and will let you know, thanks
[17:25] <garagoth> hrw: Hm, can it be because I have no arm-linux-gnueabi-gcc? It is in package gcc-4.4-arm-linux-gnueabi, but I have gcc-4.5-arm-linux-gnueabi which install /usr/bin//usr/bin/arm-linux-gnueabi-gcc-4.5
[17:26] <garagoth> and there is no symlink or anything to arm-linux-gnueabi-gcc
[17:26] <hrw> garagoth: apt-get install gcc-arm-linux-gnueabi then
[17:29] <hrw> ok, time to finish session for me
[17:29] <hrw> have a nice rest of day
[17:30] <garagoth> Oooh. I removed from PATH /usr/arm-linux-gnueabi/bin and it started working
[17:30] <hrw> ARGH YOU! :D
[17:31] <garagoth> Yes, I create errors. But without your hint I would never find it.
[17:32] <garagoth> I was missing one package
[17:32] <garagoth> So, thanks a lot and have a nice day as well :-)
[17:32]  * garagoth crossess fingers to make it compile.
[17:34] <garagoth> If I do not click 'Submit bug report' on web page, it is not visible to anyone, right?
[18:30] <zul> persia: heya im working on a fix for libvirt on arm fyi
[18:50] <jkridner> excuse the FAQs, but is there an LTS release for ARM yet and will there be an armv7 Ubuntu release?
[18:50] <jkridner> my googling is returning misleading info.
[18:53] <GrueMaster> jkridner: 12.04 will be thefirst LTS release for arm.  Armv7 has been supported since 10.04
[18:53] <GrueMaster> (but 10.04 was not LTS for arm).
[18:53] <jkridner> thanks!
[18:54] <jkridner> I think 10.04 was armel, compatible with armv7, but not optimized for armv7.
[18:54] <GrueMaster> It was the first armv7 release.
[18:55] <infinity> Our armel port has been armv7 for a while.
[18:55] <infinity> Don't confuse the dpkg arch name with the compiler target.
[18:55] <infinity> (Much like our i386 port won't actually run on 80386 machines)
[18:55] <GrueMaster> True, not all packages were built with full armv7 optimizations, but main was.
[20:00] <zumbi> ogra_: there?
[20:01] <zumbi> someone know if ubuntu still needs mx51 or omap4 subarches on debian core, more specifically debian-installer
[20:01] <zumbi> lool: ^
[20:18] <melis51> GrueMaster: hi, I changed the setenv as you suggested, but ubuntu won't boot on my beagle
[20:52] <garagoth> rsalveti: ping
[20:53] <garagoth> Hm. I am trying to compile ubuntu kernel with expansion boards support and I have encountered a problem. Some boards have irq_set_irq_type(...) invoked but it is nowwhere defined
[20:54] <garagoth> google claims it to be a standard interrupt api function...
[20:58] <garagoth> hm, it is there named set_irq_type, not irq_set_irg_type... confusing...
[20:59] <rcn-ee_at_work> garagoth, that got changed in 2.6.39...
[21:01] <rcn-ee_at_work> garagoth, 2.6.38 and earlier used "set_irq_type", 2.6.39+ uses "irq_set_irq_type"
[21:01] <garagoth> damn. One small revision number...
[21:02] <garagoth> I'm sooo close to make it work, damn...
[21:02] <garagoth> So much trouble to have i2c bus 2 working ;-)
[21:03] <rcn-ee_at_work> well the simplistic patch would just to add: "omap_register_i2c_bus(2, 400, NULL, 0);"  in the i2c section... but i thought you had a trainer board..
[21:03] <garagoth> yes
[21:04] <garagoth> I have
[21:04] <rcn-ee_at_work> well, the big patch set's everything up for the trainer.. (and more..)
[21:04] <garagoth> and I found usage for gpio, so I need more then i2c, so patching...
[21:05] <garagoth> back to soldering while kernel continues to compile...
[23:59] <persia> zumbi, Support for mx5 and omap4 continues to be useful :)
[23:59] <zumbi> persia: thanks, you mean mx51?, I realized that reading omappedia.org


[09:37] <JohannKrauss> hello. how to resolve update-alternatives: error: cannot stat file '/etc/alternatives/x-cursor-theme': Too many levels of symbolic links
[09:47] <SKYLAKE-10nm> !new
[10:51] <pepijn> What is the best way to have keyboard shortcuts work like on Mac, instead as like Windows?
[10:51] <Sysi> settings -> window manager
[10:52] <Sysi> though I don't think you can change copy&paste shortcut
[10:52] <pepijn> well, that's kind of the most important one
[10:53] <Sysi> hmm, you could map ctrl to be super/cmd but I'll need to look up a nice way to do that
[10:54] <pepijn> but if you do that you'll break the terminal, which uses ctrl+c to erminate
[10:55] <Sysi> no, then you'll just do cmd-C for that too
[10:56] <pepijn> Sysi, that is what I mean, I'll have t do cmd+shift+C to paste in the terminal
[10:57] <pepijn> The beauty of sing cmd is that you have ctrl for other stuff
[10:58] <Sysi> well that just isn't possible afaik
[10:58] <Sysi> but when you hilight text you can paste with middle click
[11:01] <pepijn> :(
[11:02] <pepijn> then I might as well not bother, because It'll never work the way I want.
[11:02] <pepijn> If I remap cmd to ctrl, I'll still need to use tab to cycle windows
[11:03] <pepijn> and press cmd+shift+C for the terminal
[11:05] <Sysi> hmm, I don't have xfce terminal at hand right now, so could you check if it has option for changing the paste key combination?
[11:06] <Sysi> some other terminal might have it even if xfce4-terminal doesn't
[11:07] <Sysi> so you could use cmd-c everywhere else, but ctrl-c in terminal
[11:13] <Oweoqi> hi all, does Xubuntu send any data of any kind to Canonical?
[11:15] <Sysi> you mean when you install it? no
[11:16] <Oweoqi>  oh no, just during every day use such as how (by default) Unity send search data to back to them
[11:16] <Oweoqi> Anything similar in Xubuntu?
[11:16] <Sysi> no, on unity you can prevent that by removing one package
[11:17] <Oweoqi> of course, this is just an example to provide context to my question
[11:17] <Sysi> I kind of figured it by myself
[11:18] <Oweoqi> cool cool, so the base of Ubuntu doesn't have anything like this?
[11:19] <Sysi> nope, it's just done by the amazon-addition in unity dash
[11:19] <brainwash> what about software center? or ubuntu one?
[11:20] <brainwash> or even package updates?
[11:20] <brainwash> they all send data to canonical :)
[11:20] <Oweoqi> oh really
[11:20] <Oweoqi> Ubuntu one makes sense
[11:21] <Oweoqi> but the other two :-.
[11:21] <Sysi> I'm doubtful about "sending" data via updates but of course they know how much stuff is downloaded, maybe even from mirrors
[11:21] <brainwash> you said "any data of any kind"
[11:22] <Sysi> I just think there's difference
[11:23] <Sysi> though I just started to reconsider that
[11:23] <Oweoqi> I'm just trying to learn about the system is all
[11:24] <Oweoqi> any data being transferred outside of a web browser is something I need to know about
[11:24] <Oweoqi> (I already know what I'm doing in the browser)
[11:25] <Sysi> http://popcon.ubuntu.com/ not sure if this is enabled by default (do you really?)
[11:26] <Oweoqi> yeah I do, it's locked down pretty tight too
[11:27] <Oweoqi> Nope popcon isn't default
[16:21] <anders_> hello there. anyone here using xubuntu and a nexus 7? I'm used to working from windows, and I cant seem to get fastboot to work etc. Googled some guides, but don't really get them. Do I need to install drivers or what is the process here? Starting from scratch
[16:23] <anders_> brb reboot
[16:29] <xubuntu938> WILL ANYBODY HELP ME FOR INSTALLING CANON LBP2900B PRINTER
[19:56] <jlack> I think there's something wrong with my sound
[19:56] <jlack> Like the pitch is higher
[19:56] <TheSheep> you sound ok to me
[19:56] <jlack> hawhaw
[19:56] <jlack> it's not my headphones
[20:12] <jlack> anyone
[20:13] <jlack> oh it's just chrome
[20:14] <Mitchell92> Hi.. I just installed my nVidia driver, now it seems like I'm using a minimaliztic theme and I can't figure out how to get it back... my top bar and such is all silver.
[20:15] <Mitchell92> it apears like 3d Acceleration isnt working.
[20:18] <rowboatnick> Mitchell92: did you change any theme settings?
[20:28] <seronis> what kind of connectivity options are available with android phones and xubuntu ?
[20:30] <SonikkuAmerica> seronis: The same as any other Ubuntu flavor - get the Android SDK, connect up and run [ adb devices ]
[20:31] <TheSheep> I don't think he meant debugging
[20:31] <seronis> SonikkuAmerica: in not referring to development.  i mean integration (already have the sdk)
[20:32] <SonikkuAmerica> seronis: Oh. What kind of integration do you need? Xubuntu, like Ubuntu, can read data from Android devices OOB
[20:33] <seronis> nothing specific.  more curious what options are available/popular other than airdroid and vnc
[20:33] <seronis> because neither of those are xubuntu specific (or even linux specific)
[20:35] <SonikkuAmerica> I don't think there's anything Xubuntu-specific
[23:36] <angelite> Hello?


[01:55] <arraybolt3[m]> Eickmeyer: Did you... write the Edubuntu website in pure HTML? I just opened it up to see if I could tell what engine you used to build it and it looks like perfectly formatted, hand-written HTML.
[01:56] <arraybolt3[m]> (I'm working on rebuilding the Lubuntu website and am using Nikola, which produces much... messier... code :P)
[01:57] <Eickmeyer> arraybolt3: That would've been aaronprisk[m], and it's at https://github.com/aaronprisk/edubuntu.org
[01:57] <Eickmeyer> It's really only a temp site until we can get Canonical to host a wordpress site.
[01:57] <arraybolt3[m]> Wow. Well that's awesome. (Funny thing, Lubuntu is trying to migrate from Wordpress to a static site :P)
[01:58] <arraybolt3[m]> WP is a massive lump of unnecessary problems for us.
[01:58] <Eickmeyer> I need it to be something easy for Amy to post to.
[01:59] <arraybolt3[m]> Ah. That makes sense.
[02:00] <Eickmeyer> She's not super technical and doesn't understand markdown, which is why she did the write-up, signed-in to discourse, and I just copied/pasted.
[02:02] <arraybolt3[m]> I wonder if there's some way to do that without Wordpress. I mean every time I've seen it used, it's just a massive headache and doesn't work half the time.
[02:02] <Eickmeyer> I did the formatting from there, and did release notes and what-not and anything technical.
[02:03] <arraybolt3[m]> Anyway, you guys know what you're doing. Just was cool to see that.
[02:04] <Eickmeyer> The Ubuntu Studio website works, just have to ask Canonical IS to clear the cache for any instantaneous changes.
[02:04] <Eickmeyer> Otherwise, just be patient and it'll update.
[02:08] <arraybolt3[m]> For us, WP has been "fantastic, I added extra buttons to the page but now one of them looks broken", "it won't let me in", "elementor is being grumpy", "oh joy only the first Imgur link is loading inline, the other two look weird", etc., etc.
[02:12] <arraybolt3[m]> Only thing that gives us more trouble is Discourse (which breaks randomly about once every two months and teward has to yell at the server loud enough to kick it back into shape).
[02:17] <Eickmeyer> That's odd, but on the other hand, lubuntu.me isn't hosted by Canonical.


[22:08] <SamB> anyone know how to turn a series of bzr commits into a set of patches ala git-format-patch?
[22:09] <SamB> hmm, having trouble getting the series at all:
[22:09] <SamB> % bzr log -p -rbzr://bzr.savannah.gnu.org/emacs/trunk.. lp:~naesten/emacs/nextstep-stuff|less > nextstep-stuff.patches
[22:09] <SamB> bzr: ERROR: Server sent an unexpected error: ('error', 'GhostRevisionsHaveNoRevno', 'Could not determine revno for {bzr://bzr.savannah.gnu.org/emacs/trunk} because its ancestry shows a ghost at {eggert@cs.ucla.edu-20120708200356-0nr2pnd47pk0ejh2}')


[01:33] <geirdal> New background images, fourth try- here: geirdal.is/index.php/studio-0
[17:53] <autumna> sakrecoer: to clarify, either day (21, or 23) is fine for me. :)
[18:49] <geirdal> what time is it for me GMT
[19:02] <geirdal> background images as suggested by Ralf, it is not nice to call geometric art logs! I dont want to make this.
[19:02] <geirdal> geirdal.is/index.php/studio-0
[19:03] <geirdal> fifth try!
[19:24] <autumna> whoa, radical change to the first image geirdal
[19:32] <autumna> geirdal: re what you said on off-topic, I actually think set 4 might work just fine (and the first image might even work better than the flat one. main issue is having enough brightness contrast between the white text and the background
[19:32] <autumna> which front graphic of 4 does better than 5
[19:33] <geirdal> aggree
[19:35] <geirdal> I will make a new version based on 4
[19:35] <geirdal> with more contrast
[19:35] <autumna> more contrast with the text right?
[19:36] <geirdal> right
[19:36] <autumna> I think this might be fine
[19:36] <autumna> maybe a bit less contrast within the image. (so that it is the same amount of contrast the section ones have)
[19:36] <autumna> but seriously
[19:36] <autumna> it might be readable as it is
[19:37] <autumna> its a bit busy
[19:37] <autumna> but.. yeah, do you have a copy of the image without the text on top?
[19:37] <geirdal> we will see, its good to have something to choose from
[19:37] <geirdal> ofcours
[19:38] <autumna> *nods*
[19:38] <geirdal> i will post a link
[19:40] <autumna> thanks :D
[19:49] <geirdal> it need more work on the contrast but I think we are on the right track http://geirdal.is/index.php/studio-0
[19:53] <geirdal> they arre in  1280 × 720 pixels like sakrekoer suggested to me
[19:56] <autumna> *replaces it at the feature test
[19:57] <geirdal> send me link, Ive lost it :P
[19:58] <geirdal> this one ? http://www.ubuntustudio.zequence.net/feature-test/
[19:58] <autumna> yep
[19:58] <autumna> sorry I was just logging in
[19:58] <geirdal> ok ;)
[20:05] <geirdal> take the backround of the text autumna, can you do that :)
[20:05] <autumna> actually I was just doing that
[20:06] <autumna> done
[20:06] <geirdal> :))))
[20:07] <geirdal> good readability? Yes
[20:07] <autumna> yeah I don't see any major issues with it
[20:07] <autumna> well
[20:07] <autumna> ok it still is very busy
[20:07] <autumna> which is not ideal
[20:07] <autumna> but I will also still try to see if I can add the blur in there
[20:10] <geirdal> ok


[10:07] <zxzx> hello there
[10:07] <zxzx> budgee seems promising
[10:17] <v3n0m> hi
[10:18] <v3n0m> i got a problem