[02:10] -queuebot:#ubuntu-release- Unapproved: containerd (bionic-proposed/universe) [1.2.6-0ubuntu1~18.04.2 => 1.3.3-0ubuntu1~18.04.1] (no packageset)
[02:11] -queuebot:#ubuntu-release- Unapproved: containerd (eoan-proposed/universe) [1.2.10-0ubuntu1 => 1.3.3-0ubuntu1~19.10.1] (no packageset)
[07:05] -queuebot:#ubuntu-release- Unapproved: postgresql-9.5 (xenial-proposed/main) [9.5.19-0ubuntu<IP_ADDRESS> => 9.5.21-0ubuntu<IP_ADDRESS>] (core)
[10:30] <ginggs> would someone please 'force-badtest psi4/1:1.3.2-3build1/i386' ?
[10:47] -queuebot:#ubuntu-release- Unapproved: accepted ec2-instance-connect [source] (eoan-proposed) [1.1.12+dfsg1-0ubuntu3~19.10.0]
[11:10] -queuebot:#ubuntu-release- Unapproved: accepted ec2-instance-connect [source] (bionic-proposed) [1.1.12+dfsg1-0ubuntu3~18.04.0]
[11:18] -queuebot:#ubuntu-release- Unapproved: accepted ec2-instance-connect [source] (xenial-proposed) [1.1.12+dfsg1-0ubuntu3~16.04.0]
[13:12] <ahasenack> hi release team, haproxy isn't being built for i386, could its dep8/i386 tests be hinted please?
[13:13] <ahasenack> https://launchpad.net/ubuntu/+source/haproxy/2.0.13-1ubuntu2
[13:13] <ahasenack> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#haproxy
[13:44] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (bionic-proposed/main) [1.1ubuntu<IP_ADDRESS> => 1.1ubuntu<IP_ADDRESS>] (desktop-core, ubuntu-server)
[13:44] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (trusty-proposed/main) [0.82.1ubuntu2.5 => 0.82.1ubuntu2.6] (kubuntu, ubuntu-desktop, ubuntu-server)
[13:44] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (eoan-proposed/main) [1.14ubuntu1.1 => 1.14ubuntu1.2] (core)
[13:44] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [1.1ubuntu<IP_ADDRESS>~16.04.5 => 1.1ubuntu<IP_ADDRESS>~16.04.6] (desktop-core, ubuntu-server)
[14:40] -queuebot:#ubuntu-release- New source: wireguard-linux-compat (eoan-proposed/primary) [0.0.20200205-1ubuntu1~19.10.1]
[14:41] -queuebot:#ubuntu-release- Unapproved: wireguard (eoan-proposed/universe) [0.0.20190913-1ubuntu1 => 1.0.20200206-1ubuntu1~19.10.1] (no packageset)
[14:56] -queuebot:#ubuntu-release- Unapproved: rtl8821ce (eoan-proposed/universe) [<IP_ADDRESS>-0ubuntu1~19.10.1 => <IP_ADDRESS>-0ubuntu3~19.10.1] (no packageset)
[14:58] -queuebot:#ubuntu-release- Unapproved: rtl8821ce (bionic-proposed/universe) [<IP_ADDRESS>-0ubuntu1~18.04.1 => <IP_ADDRESS>-0ubuntu3~18.04.1] (no packageset)
[15:32] -queuebot:#ubuntu-release- New sync: php-guzzlehttp-promises (focal-proposed/primary) [1.3.1-2]
[15:32] <seb128> http://autopkgtest.ubuntu.com/packages/o/openscad/focal/s390x should probably marked to skip/badtest since it regressed with the new mesa and isn't an issue in proposed
[15:32] <seb128> tjaalton, ^ did you discuss that?
[15:33] <seb128> vorlon, ^ pinging since you rebuilt it for a transition so you probably want to see it unblocked
[16:15] <vorlon> seb128: thanks, hint bumped
[16:15] <vorlon> also the hint says to hassle tjaalton when bumping the hint, about the upstream fix
[16:17] <LocutusOfBorg> vorlon, is it possible to hint haproxy/i386 and libapache2-mod-perl2/i386 please?
[16:18] <LocutusOfBorg> xnox, are you looking at hilive/arm64 to make boost candidate? it regressed in release, not sure if worth an hint or a fix...
[16:19] <LocutusOfBorg> or maybe it should be moved to a machine with more ram
[16:19] <xnox> LocutusOfBorg:  i'm looking into both boost and icu yes, but it is a bit tedious. But slowly making progress on both.
[16:21] <LocutusOfBorg> xnox, I'm helping here and there since I want to do ocaml after them :)
[16:22] <LocutusOfBorg> let me know if I can do anything, right now I'm picking random failures and fixing them
[16:22] <LocutusOfBorg> e.g. I will do taglib now
[16:22] <LocutusOfBorg> oh, already done
[16:22] <xnox> LocutusOfBorg:  random is good =)
[16:22] <xnox> LocutusOfBorg:  you are working off the transition trackers right?
[16:23] <LocutusOfBorg> yes!
[16:23] <xnox> cool cool
[16:23] <LocutusOfBorg> for some reasons looks like hilive in my localhost arm64 chroot is hanging too
[16:23] <LocutusOfBorg> or maybe it needs some more time, because of qemu foo
[16:32] <rbalint> sil2100, could you please check the unatended-upgrades sru uploads in unapproved?
[16:40] <sil2100> rbalint: o/
[16:49] <LocutusOfBorg> also pacemaker/i386 needs an help...
[16:50] <LocutusOfBorg> needs a bump of the hint ^^
[17:15] <sil2100> rbalint: hm, what is the actual test-case for the u-u ESM changes?
[17:15] <sil2100> rbalint: I assume it requires some special permissions?
[17:23] <sil2100> rbalint: I guess we'll anyway have to have the 'right' someone testing that, so let me proceed and accept
[17:24] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (eoan-proposed) [1.14ubuntu1.2]
[17:26] <rbalint> sil2100, thanks!
[17:27] <rbalint> sil2100, a simpler test case would be just observing the list of allowed origins, but it the bug reporter verifies if the pockets actually work, it is just better imo
[17:41] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (bionic-proposed) [1.1ubuntu<IP_ADDRESS>]
[17:42] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [1.1ubuntu<IP_ADDRESS>~16.04.6]
[18:08] -queuebot:#ubuntu-release- New binary: linux-signed [s390x] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
[18:08] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-89.89] (core, kernel)
[18:08] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-175.205] (core, kernel)
[18:08] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
[18:10] -queuebot:#ubuntu-release- Unapproved: quassel (xenial-proposed/universe) [0.12.2-0ubuntu1 => 0.12.2-0ubuntu<IP_ADDRESS>] (no packageset)
[18:11] -queuebot:#ubuntu-release- Unapproved: quassel (bionic-proposed/universe) [1:0.12.4-3ubuntu1 => 1:0.12.4-3ubuntu<IP_ADDRESS>] (no packageset)
[18:12] -queuebot:#ubuntu-release- Unapproved: quassel (eoan-proposed/universe) [1:0.13.1-1ubuntu1 => 1:0.13.1-1ubuntu<IP_ADDRESS>] (kubuntu)
[18:22] <RikMills> vorlon: could you please bump or otherise amend the pyside2 hint? that baseline reset is not working well now there has been a new upload which got some 'neutral' test results :/
[18:26] <vorlon> RikMills: 'neutral'->'fail' should be considered a regression, and there should be a justification for overriding.  Do you know why the tests are failing looking for python3.7, when 4 days prior they were failing looking for python3.8?
[18:27] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
[18:36] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-89.89] (core, kernel)
[18:52] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-175.205]
[18:59] <RikMills> vorlon: presumably the python3 defaults migration caused that switch
[19:03] <RikMills> i.e. failing to find X-Python3-Version, it is falling back to the default python which is now 3.8
[19:09] <RikMills> I guess py3versions must be returning both, and the one not found has now switched
[19:14] <RikMills> yeah, it a chroot with test deps, that seems to be the case
[19:14] <RikMills> *in a
[19:24] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-89.89]
[19:24] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-89.89]
[19:28] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (eoan-proposed/main) [5.3.0-41.33] (core, kernel)
[19:32] <tjaalton> seb128, vorlon: upstream 20.0rc has a revert in it that might fix it. i'll push that to focal later this week when i'm back
[21:14] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (eoan-proposed) [5.3.0-41.33]
[21:14] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (eoan-proposed) [5.3.0-41.33]
[21:14] -queuebot:#ubuntu-release- New: accepted linux-signed [arm64] (eoan-proposed) [5.3.0-41.33]
[21:14] -queuebot:#ubuntu-release- New: accepted linux-signed [s390x] (eoan-proposed) [5.3.0-41.33]
[21:24] -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (eoan-proposed) [1.3.3-0ubuntu1~19.10.1]
[21:29] -queuebot:#ubuntu-release- Unapproved: accepted containerd [source] (bionic-proposed) [1.3.3-0ubuntu1~18.04.1]
[21:31] <mwhudson> bdmurray: thanks
[21:39] <bdmurray> mwhudson: no problem
[22:58] <mwhudson> sigh i wish launchpad tracked rebuild attempts
[23:20] -queuebot:#ubuntu-release- New binary: wcslib [amd64] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
[23:25] -queuebot:#ubuntu-release- New binary: wcslib [s390x] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
[23:31] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1033.35] (kernel)
[23:31] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (eoan-proposed/main) [5.3.0-1014.15] (core, kernel)
[23:31] -queuebot:#ubuntu-release- New binary: linux-signed-oem [amd64] (bionic-proposed/main) [4.15.0-1073.83] (kernel)
[23:31] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (eoan-proposed/main) [5.3.0-1013.14] (core, kernel)
[23:34] -queuebot:#ubuntu-release- New binary: wcslib [arm64] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
[23:34] -queuebot:#ubuntu-release- New binary: wcslib [armhf] (focal-proposed/universe) [7.1+ds-2] (kubuntu)
[23:58] -queuebot:#ubuntu-release- New binary: wcslib [ppc64el] (focal-proposed/universe) [7.1+ds-2] (kubuntu)


[08:29] <punxos> Hi
[13:23] <hrw> I do wonder will we have arm64 with multilib for armel/armhf
[13:24] <ogra_> ugh
[13:24] <ogra_> scary thought
[13:25] <hrw> I have worse one ;)
[13:25] <hrw> arm64 or arm64sf or arm64hf?
[13:26] <ogra_> i guess that depends what we choose as default for precise
[13:26] <ogra_> and dont expect an arm64 arch at all this release
[13:26] <hrw> I do not
[13:26] <ogra_> we will likely have 32bit userspace
[13:26] <ogra_> and a 64bit kernel
[13:26] <hrw> I do not expect arm64 before q/r
[13:26] <ogra_> as of el or hf, we will only decide by feature freeze
[13:28] <lilstevie> wait there is a 64bit arm proc?
[13:28] <ogra_> no
[13:29] <hrw> lilstevie: arm announced it ~2 weeks ago
[13:29] <lilstevie> thats what I thought
[13:29] <lilstevie> ah
[13:29] <ogra_> thats why we dont care about that arch yet
[13:29] <lilstevie> I missed the announcement
[13:29] <hrw> lilstevie: so far only fpga implementations
[13:29] <ogra_> there will be
[13:29] <lilstevie> I see
[13:29] <lilstevie> I really want a T3 in my hands
[13:29]  * ogra_ just wants a 4U calxeda box
[13:29] <lilstevie> the 4+1 concept is rather clever
[13:30] <ogra_> thats just ~300 cores and 300GB RAM
[13:30] <lilstevie> lol wow
[13:31] <ogra_> (and 300 SATA ports)
[13:31] <lilstevie> thats a lot of drives
[13:31] <ogra_> one per core
[13:32] <lilstevie> yeah figured
[13:32] <hrw> ogra_: but you want some of storage modules in this 4U too?
[13:32] <lilstevie> 1GB ram 1 SATA per core
[13:32] <ogra_> hrw, i have a spare cabinet, they can go into a second box :P
[13:32] <lilstevie> heh
[13:33] <dmart> hrw, ogra_: I think hard-float will be mandatory for AArch64.  So there might just be an aarch64 ABI, which is completely separate from arm*.  32-bit binaries should be able to live under a 64-bit kernel using multiarch.  But this is all way in the future
[13:33] <lilstevie> I hate messy hacks for kernel drivers :/
[13:33] <ogra_> with that setup i could make the raspberry pi people happy :) rebuild the whole archive in 1day :)
[13:33] <ogra_> dmart, yeah, and we still dont have hf yet
[13:34] <lilstevie> raspberry pi is not armv7?
[13:34] <ogra_> nope
[13:34] <ogra_> v5 afaik
[13:35] <lilstevie> ew
[13:35] <dmart> ogra_: Don't they just use Debian armel for now?  Given the limited capabilities of the device, that seems reasonable
[13:36] <ogra_> yes, i hope they do, though there was discussion about fedora as well
[13:36] <ogra_> not sure what they decided on as their default
[13:37]  * ogra_ has plenaty of personal flame mails from raspberry people ranting about ubuntu not going back to v5
[13:38] <dmart> They should rant at the rpi folks for not choosing a v7 CPU ;)
[13:38] <ogra_> heh, yeah
[13:38] <ogra_> well, i was the one who answered in the bug that asks for supporting the raspberry
[13:39] <ogra_> telling that it would take plenty of resources and that they are free to offer these to canonical for maintining a v5 community port ....
[13:42] <hrw> pi is armv6
[13:43] <ogra_> ah
[13:43] <ogra_> well, not much better though ... from an ubuntu POV
[13:43] <hrw> aye
[13:44] <lilstevie> all of those plug devices should use better CPUs really
[13:44] <ogra_> well, the next guruplug will be v7 i heard
[13:45] <dmart> I still think that the subset of software in Ubuntu which will actually work on this board is also in Debian anyway.  The rpi folks could hopefully create suitable Debian images as a community effort on their side
[13:45] <ogra_> thats what i always suggest
[13:46] <ogra_> what happened to the linaro idea to make the archive easily recompilable for lower level arches ?
[13:46] <ogra_> was that dropped ?
[13:50] <dmart> ogra_: Well, really we want to be able to recompile for _newer_ arches (like armhf).  In practice, I think that's being done the old-fashioned way, though we do have quite a lot of cross-buildable packages, and cross-building support is gradually improving with multiarch etc.  Linaro focuses on current and future stuff, so pre-v7 not likely ever to be a priority.
[13:51] <ogra_> ah, i thought the idea behind it was to help customers that want pre-v7
[13:51] <lilstevie> hf would be nice
[13:51] <ogra_> hf is in the works
[13:51] <ogra_> autobuilds should start some time this week
[13:51] <ogra_> the question is if it will be ready for precise
[13:52] <dmart> ogra_: That's not an explicit goal, though mutiarch should make this a bit easier
[13:52] <ogra_> we will decide that by FF
[13:52] <lilstevie> fair enough
[13:53] <lilstevie> I tried mer on the TF which is hf
[13:53] <lilstevie> perf is really orders better
[13:53] <dmart> ogra_: Presumably, mutiarch should allow armhf and armel binaries to be co-installable?  I think that was the idea.  We should only rely on this for multiverse etc. though -- the core system should really stick to one ABI, otherwise we end up with a lot of duplicate libraries etc.
[13:58] <ogra_> dmart, i'm not sure4 that works atm
[13:58] <ogra_> infinity could tell though, but iirc there were issues with multiarch last i heard
[13:59] <dmart> I think it's still a work in progress, but my understanding was that it's _supposed_ to work, at least in the precise timescale.  I'm not involved in that though, so I could be wrong
[14:00] <ogra_> well, hf was *supposed* to be ready during the oeniric timeframe :P
[14:00] <ogra_> so much about timeframes :)
[14:00] <lilstevie> heh
[14:01] <dmart> oh, right.   I said I could be wrong ;)
[14:01] <lilstevie> yeah I thought there was some soft/hard abi incompatibilities
[14:01] <lilstevie> and that it was all or nothing
[14:01] <ogra_> well, multiarch was supposed to solve it
[14:02] <ogra_> but rather on a theoretical level yet
[14:03] <suihkulokki> multiarch works, but there is a snatch in that both armel and armhf use /lib/ld-linux.so.3 as dynamic linker
[14:03] <suihkulokki> but people (eg infinity and sledge) are fixing that
[14:03] <ogra_> yeah, that was it
[14:04] <ogra_> suihkulokki, well, not sure ... he might skip that part to finally get the pressure off to actually *have* hf at all
[14:04] <ogra_> it has to happen real soon, else we'll not be able to make precise
[14:06] <dmart> Ah, I remember that one
[14:06] <dmart> Changing the ld.so path does require absolutely everything to get rebuilt though :(
[14:07] <ogra_> right
[14:07] <suihkulokki> naah, that's just buildd time
[14:07] <ogra_> which we dont have at all
[14:08] <ogra_> given that we put double load on them already
[14:08] <lilstevie> I should set my trimslice up to do more building for me
[14:09] <ogra_> heh
[14:10] <dmart> Actually, we just need a tool to poke something else in the DT_INTERP field of existing binaries...
[14:57] <shadeslayer> lilstevie: got a sec?
[14:57] <lilstevie> shadeslayer: kinda
[14:57] <shadeslayer> lilstevie: ok, I was trying to boot ubuntu via the chroot method now we have a local exploit thanks to you guys
[14:58] <shadeslayer> ( thanks a ton for that! )
[14:58] <shadeslayer> The problem is that the script has a modprobe ext2 command which is failing
[14:58] <shadeslayer> modprobe: chdir(/lib/modules): No such file or directory << Any ideas where I can find that?
[14:59] <lilstevie> I have no idea about chroot
[14:59] <shadeslayer> alright, thanks anyways :)
[15:00] <lilstevie> I don't like/support/work on or condone the use of chrooted environments
[15:00] <lilstevie> :p
[15:02] <shadeslayer> lilstevie: yeah, well, seeing how I can't flash ubuntu natively yet, this is a workaround ;)
[15:02] <lilstevie> heh yeah
[15:02] <lilstevie> well you could loop mount :p
[15:03] <shadeslayer> yeah, I'll have a go at that after dinner
[15:03] <shadeslayer> I also get : chroot: can't execute '/bin/bash': No such file or directory .. weird
[15:16] <shadeslayer> hah
[15:16] <shadeslayer> lilstevie: I don't think the stock kernel has loopback support
[15:19] <lilstevie> shadeslayer: you can flash a custom kernel though
[15:19] <shadeslayer> lilstevie: uh, custom kernel or custom ROM?
[15:20] <shadeslayer> I've never flashed a custom kernel before ...
[15:21] <lilstevie> both
[15:21] <lilstevie> key is don't flash both at once
[15:22] <lilstevie> flashing both at once == brickable chance
[15:22] <shadeslayer> ah ok, Is there a well documented wiki or something for this out there? I'll read up on it before I do something nasty
[15:23] <lilstevie> not really
[15:23] <lilstevie> these are the nasty hacks
[15:23] <shadeslayer> hehe ^^
[15:23] <lilstevie> I am working on building an apk to do the nasty hacks in a sane way
[15:23] <shadeslayer> lilstevie: any progress on the miniloader situation that you guys had a couple of weeks earlier?
[15:24] <lilstevie> nop
[15:24] <shadeslayer> oh fooey ... so no native ubuntu for the next couple of weeks then
[15:26] <shadeslayer> lilstevie: so whats this new APK that you're making? :)
[15:26] <lilstevie> using some really ugly hacks to install ubuntu
[15:27] <shadeslayer> natively or chroot?
[15:29] <lilstevie> natively
[15:29]  * lilstevie would never chroot
[15:29] <shadeslayer> zomg
[15:29] <shadeslayer> lilstevie: <3
[15:30] <shadeslayer> alright then, I'll wait it out for your app
[18:05] <pnphi> hello
[18:06] <pnphi> join now
[18:06] <pnphi> alo
[18:09] <pnphi> alo
[18:09] <int_ua> pnphi: who are you talking to?
[18:09] <pnphi> hi all
[18:09] <pnphi> please..help me..
[18:09] <int_ua> :)
[18:10] <pnphi> how to building image ubuntu for ARM,step by step.
[18:10] <int_ua> pnphi: what is your target device?
[18:10] <pnphi> Beagleboard
[18:11] <int_ua> pnphi: Did you try preinstalled images?
[18:11] <int_ua> pnphi: Did you check https://wiki.ubuntu.com/ARM/Beagle ?
[18:12] <pnphi> the link...this is install ubuntu on ARM
[18:13] <GrueMaster> Exactly what the beagleboard is running.
[18:13] <pnphi> how to create image ubuntu on ARM
[18:13] <GrueMaster> Download the preinstalled image, flash to SD, boot.
[18:13] <GrueMaster> What exactly are you trying to do?
[18:14] <pnphi> i can install ubuntu on ARM
[18:14] <pnphi> but i want to ... how create this image
[18:15] <pnphi> i'm know english very bad....i'm come from Vietnamess
[18:15] <GrueMaster> infinity: Care to explain how we build images?
[18:16] <pnphi> step by step ... create image ubuntu for ARM
[18:17] <GrueMaster> pnphi: Unfortunately, other team members are very busy with getting 12.04 started, but the short answer is we have a series of scripts that build the images from scratch on an arm platform, then bundle them up into a single pre-installed image for users.  I don't have the specifics on the process.
[18:19] <GrueMaster> If you are looking to create your own image, I would recommend starting with our ubuntu-core images on http://cdimage.ubuntu.com (see https://wiki.ubuntu.com/Core for more info).
[18:19] <pnphi> oh i understan
[18:19] <GrueMaster> It is essentially a stripped down chroot envirnment that you can install packages into.  It has just enough functionality to do apt-get install.
[18:19] <int_ua> pnphi: It looks like you need just to install it, not to build. Am i right?
[18:20] <pnphi> no no...i need how to create this image...i can install this image
[18:22] <pnphi> from ubuntu source...how to create image for ARM... ?
[18:25] <GrueMaster> From source?  You mean recompile each package and build an image from there?  Way beyond the scope of this channel.
[18:25] <pnphi> the same
[18:36] <pnphi> i'm mad with this problem
[18:37] <pnphi> join nơ
[18:37] <pnphi> join now
[18:37] <GrueMaster> Why do you want to create an image from source?  Why not just use our images?
[18:38] <pnphi> my graduation project
[18:39] <pnphi> I do not have to create images for business
[18:41] <GrueMaster> In that case, part of your education should be learning the steps needed to build packages, and with those packages, build an image.  Asking someone for these steps doesn't teach you how to do it.  There are plenty of books and reading material online that describe how to create debian/ubuntu packages, images, etc.  I recommend more study time.
[18:42] <pnphi> in my school, teachers did not teach me, so I came here
[18:42] <GrueMaster> What type of class?  Document writing or programming.  If programming, they should fire your teachers.
[18:43] <pnphi> My school is not good
[18:43] <pnphi> so i come here
[18:43] <pnphi> i can create a package
[18:43] <pnphi> i can create a package for ARM
[18:45] <pnphi> my school don't has any teacher who pro about this problem
[18:46] <pnphi> so i come here...i need the help
[18:48] <pnphi> I write not good english so please ignore
[18:48] <GrueMaster> Unfortunately, we really do not have the time/resources to help with that level of complexity on this channel.  Which is why I recommend searching the internet for documentation (I know there is good material out there, I just don't have any links handy).
[18:48] <pnphi> can you give me the Document ? ?
[18:49] <pnphi> i need only
[18:49] <pnphi> please
[18:49] <ogra_> there is no single document for this
[18:50] <ogra_> if you really want to build ubuntu from source i would start with learning how to set up a buildd ...
[18:50] <pnphi> i know...this is very large
[18:50] <GrueMaster> You can start here:  https://www.google.com/search?client=ubuntu&channel=fs&q=ubuntu+image+building&ie=utf-8&oe=utf-8
[18:50] <GrueMaster> Tons of links.
[18:50] <ogra_> once you have the archive compiled (in a few months) you can read up about live-build and debian-cd
[18:50] <pnphi> oh my god
[18:51] <pnphi> i need specific....please
[18:51] <GrueMaster> We have over a dozen systems building packages constantly.  Which is why I said this is no easy undertaking.
[18:52] <pnphi> i know
[18:52] <GrueMaster> several packages take hours/days to build on better hardware than a beagleboard.
[18:53] <ogra_> if you really want to build from scratch i would recommend another distro
[18:53] <ogra_> ubuntu is not designed for this
[18:53] <gildean> or how about: https://launchpad.net/project-rootstock
[18:53] <GrueMaster> The kernel is around 12 hours to build.  LibreOffice is 3 days.
[18:53] <ogra_> have a look at angstrom
[18:53] <ogra_> gildean, that doesnt compile any packages
[18:53] <pnphi> what is distro ?
[18:53] <ogra_> (and is unmaintained)
[18:53] <gildean> nope, i didn't read enough to know that's necessary
[18:54] <ogra_> pnphi, ubuntu is a distro (distribution) of software ...
[18:55] <ogra_> angstrom is a distro that you can easily build from source and it works fine on the beagleboard
[18:55] <pnphi> but my project need ubuntu for ARM on beagle
[18:56] <ogra_> http://www.angstrom-distribution.org/
[18:58] <pnphi> i will die.....
[18:58] <gildean> i wonder wether the å is supposed to be pronounced as an o or as an a in that name
[18:59] <ogra_> eeengstrreeem :)
[19:00] <gildean> ongström
[19:00] <ogra_> it think its more like Ä
[19:00] <gildean> if it's supposed to be a swedish o, then it's more like an o
[19:02] <pnphi_> join now
[19:04] <gildean> good for you
[19:04] <pnphi_> huhu not good
[19:06] <pnphi_> i don't know ...i begin where ? ?
[19:07] <gildean> imho ogras idea about switching your project to ångström makes a lot of sense
[19:07] <gildean> http://www.angstrom-distribution.org/building-angstrom
[19:10] <pnphi_> please sent for me any document about how to create image ubuntu for ARM
[19:10] <pnphi_> thank you so much
[19:10] <pnphi_> thanks all
[19:12] <gildean> if you read any of the answers before, it was clearly stated that building everything from scratch with ubuntu is a huge undertaking
[19:13] <gildean> especially if you're doing it alone
[19:13] <ogra_> on a beagle
[19:13] <gildean> on a single beagle
[19:13] <ogra_> right
[19:13] <pnphi_> i have time
[19:14] <ogra_> how long ?
[19:14] <pnphi_> i have 7 mouth
[19:14] <pnphi_> or more
[19:14] <pnphi_> i have 7 mounths
[19:14] <pnphi_> or more
[19:15] <pnphi_> and my group have 2 members
[19:15] <pnphi_> and 2 teachers
[19:16] <gildean> do you really want to build *everything* from scratch?
[19:16] <gildean> i mean, ubuntu is basically the distro that was made so you wouldn't have to build anything
[19:17] <pnphi_> yes,,i want from source of ubuntu ...so i will create image for ARM
[19:18] <gildean> yes, but you can create an image without building any packages?
[19:18] <gildean> if you want to build everything, distros like gentoo or ångström would fit your need much better
[19:18] <pnphi_> i understand
[19:19] <pnphi_> maybe...this problem is very hard for me
[19:20] <gildean> at what level?
[19:20] <pnphi_> i don't understand ?
[19:21] <pnphi_> this is hard because i don't know beging at where
[19:22] <ogra_> learn about ho to set up a buildd
[19:22] <ogra_> *how
[19:22] <pnphi_> step by step ? ?
[19:23] <pnphi_> can you help me ?
[19:23] <ogra_> no
[19:23] <ogra_> we dont do such stuff
[19:23] <ogra_> we use the existing infrastructure of ubuntu
[19:23] <ogra_> we upload source packages to launchpad where a buildd builds them
[19:24] <pnphi_> clearer? ?
[19:24] <ogra_> if you want to recompile everything from source setting up a buildd is your first setp you need to so
[19:24] <ogra_> *do
[19:24] <ogra_> find documentation on the internet about how to set up a buildd
[19:25] <pnphi_> ok
[19:25] <pnphi_> and what else ?
[19:25] <ogra_> well, that will keep you busys for a few months
[19:25] <pnphi_> no problem
[19:26] <ogra_> if you have set up the buildd you take the ubuntu source packages from ports.ubuntu.com and upload them to your buildd
[19:26] <ogra_> since the only b uildd hardware you have currently is a beaglebaord that will take very very long
[19:26] <pnphi_> oh my go
[19:26] <pnphi_> god
[19:27] <ogra_> once you have done this, you can read about how to use live-build which is what we use to create a root filesystem from the .deb packages
[19:27] <pnphi_> can you share your document for me ?
[19:27] <ogra_> there is no document
[19:27] <ogra_> search on google
[19:28] <pnphi_> ok
[19:28] <ogra_> learn about buildds first
[19:28] <ogra_> set one up on your beagle
[19:28] <ogra_> upload the packages
[19:28] <ogra_> if you are done, feel free to come back
[19:29] <pnphi_> ok
[19:29] <pnphi_> oh i have a ques...
[19:30] <pnphi_> apt-get  source -d package ... i will have a source package
[19:30] <ogra_> yes
[19:30] <pnphi_> where is dep of pack ?
[19:30] <pnphi_> dependency
[19:31] <suihkulokki> is there a bug# for chromium-browser not building on arm?
[19:31] <pnphi_> where is dependency of package ?
[19:31] <ogra_> suihkulokki, ask micahg in #ubuntu-devel or -desktop
[19:31] <ogra_> he maintains it and should know about it
[19:32] <infinity> suihkulokki: http://qa.ubuntuwire.com/ftbfs/ doesn't show any bugs tagged FTBFS.
[19:32] <ogra_> pnphi_, probably you should first read the debian new maintainer guide (google it), it will teach you about how packages work
[19:32] <ogra_> infinity, it failed since two releases or so
[19:32] <ogra_> if tehre is a bug its very old
[19:33] <pnphi_> ok
[19:33] <infinity> ogra_: Sure, but if it's correctly tagged, the scripts will pick it up.  Or, so I understand it anyway.
[19:33] <ogra_> ah, well ...
[19:33] <ogra_> i doubt its tagged anyhow :P
[19:34]  * suihkulokki grunts
[19:34] <ogra_> but micah knows about the issues with this package and seeks help
[19:35] <pnphi_> Building the Ubuntu BeagleBoard Kernel
[19:46] <pnphi_> thank you so much
[19:47] <pnphi_> i go to sleep...in VietNam,,,now 2h48m AM
[19:48] <pnphi_> bye all
[19:48] <pnphi_> have a good day
[19:48] <pnphi_> thanks all
[21:12] <int_ua> apachelogger: Did you have problem with 2.6.35 kernel booting with u-boot when you was working on it for the N900?
[21:16] <int_ua> I just tried 3.1.0-2 and it behaves as other: just shuts down after startup without showing anything. I remember you've said something about initramfs, but the 2.6.35 boots with just mkimage and none of the other kernels I've tried do.


[04:23] <mup> Bug #1461659 changed: UEFi x64 failing to deploy on HP ProLiant DL380 Gen9 <canonical-bootstack> <curtin:Incomplete> <MAAS:Expired> <https://launchpad.net/bugs/1461659>
[10:15] <mup> Bug #1483193 opened: Time column heading for events on node details page mis-aligned <landscape> <MAAS:New> <https://launchpad.net/bugs/1483193>
[10:18] <mup> Bug #1483193 changed: Time column heading for events on node details page mis-aligned <landscape> <MAAS:New> <https://launchpad.net/bugs/1483193>
[10:21] <mup> Bug #1483193 opened: Time column heading for events on node details page mis-aligned <landscape> <MAAS:New> <https://launchpad.net/bugs/1483193>
[11:21] <mup> Bug #1483206 opened: Failed RAID creation leaves raid filesystem on device <MAAS:Confirmed> <https://launchpad.net/bugs/1483206>
[13:31] <mup> Bug #1482385 changed: boot-sources disappear after import <cisco> <landscape> <MAAS:Invalid> <https://launchpad.net/bugs/1482385>
[14:19] <mup> Bug #1483273 opened: 1.8 machine details should show the cluster name instead of DNS name <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1483273>
[14:25] <mup> Bug #1483273 changed: 1.8 machine details should show the cluster name instead of DNS name <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1483273>
[14:31] <mup> Bug #1483273 opened: 1.8 machine details should show the cluster name instead of DNS name <ui> <ux> <MAAS:New> <https://launchpad.net/bugs/1483273>
[15:37] <mup> Bug #1483303 opened: releasing failed <MAAS:Triaged> <https://launchpad.net/bugs/1483303>
[15:37] <mup> Bug #1483305 opened: maasclient-0.3 missing dependency for requests-oauthlib <MAAS:New> <https://launchpad.net/bugs/1483305>
[16:06] <roaksoax> 4/win 8
[16:49] <mup> Bug #1483332 opened: Deploying / Releasing a node sometimes yield into power status not available until next 5 min next <MAAS:New for blake-rouse> <https://launchpad.net/bugs/1483332>
[20:38] <_ad> Hi. I have set up region controller and made sure that it was the only DHCP server running. I am now trying to add a node use PXE and automatic discovery. I get an E18 then an E53 when booting my other server.
[20:38] <_ad> any ideas on other troubleshooting steps?


[02:15] <InPhase> Ooo.  Yay.  This looks like excellent progress on finally resolving those "close it" notices.  https://github.com/snapcore/snapd/pull/12574
[02:15] <mup> PR #12574: o/snapstate: pre-download and monitor snap for auto-refresh <Pulse> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12574>