[07:13] <RAOF> Hey, tjaalton: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1845317 is already fixed in eoan, right?
[07:15] <tjaalton> RAOF: bah no.. forgot to add it to the new version.. will fix in -1u2
[07:16] <tjaalton> hmm actually
[07:16] <tjaalton> the new pci-id's are there
[07:17] <tjaalton> just the marketing name changes are missing, which isn't critical for this bug
[07:23] <tjaalton> RAOF: nope, some cfl id's are missing, I'll upload -1u2
[07:23] <RAOF> Ta
[07:33] <tjaalton> RAOF: will you still accept it? projects are waiting for the update
[07:34] <RAOF> tjaalton: Sure, if the fix is heading to eoan shortfly.
[07:34] <tjaalton> great, thanks
[07:39] <tjaalton> uploaded
[11:10] <ddstreet> rbalint hi, i'm wondering why you added this https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-eoan&id=053719c8971705307aa8cb5cbcd679defa89f70a
[11:10] <ddstreet> is there something i'm missing?
[11:37] <rbalint> ddstreet, it was added in https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-eoan&id=b09b6ed4682 and when i merged 241 i accidentally merged it away making the script using ret=1-s and fail-s
[11:38] <ddstreet> rbalint but why did you add it back?  it's not needed, in fact it makes things worse
[11:38] <rbalint> ddstreet, to keep it consistent i readded it, but we can drop the whole ret=... part and use only fails
[11:39] <ddstreet> well it skips calling fail() which gathers info
[11:39] <ddstreet> which can be useful debugging failures
[11:39] <ddstreet> i'm just not seeing the benefit of adding it as an ubuntu-specific patch...
[11:41] <rbalint> ddstreet, i agree, let's convert all the ret=... parts to fail ...
[11:41] <ddstreet> rbalint honestly i'd prefer if the entire boot-smoke test was pulled from debian, there are various other issues in the one we carry
[11:46] <rbalint> ddstreet, looking at the (salsa)/master..ubuntu-eoan delta we have extra checks, but if all of those are found to be obsolete then sure, carrying less delta is better
[11:48] <rbalint> ddstreet, i see open PR-s on https://salsa.debian.org/systemd-team/systemd/merge_requests and mine does not progress, so i did not look into trying to push delta pieces to Debian more actively
[12:08] <ahasenack> good morning
[12:26] <rbalint> ddstreet, i'm dropping the ret=... parts with 243, it is a bit late for 242 if you don't mind
[12:26] <ddstreet> yep that's fine, not really a big deal either way
[12:29] <rbalint> ddstreet, i'm prepping next 242 upload in ppa:ci-train-ppa-service/3797 , if you have something urgent for eoan, please ping me
[14:26] <tjaalton> launchpad git down?
[14:26] <rbasak> It was (short notice scheduled outage) but was reported to be back now.
[14:26] <rbasak> Check #launchpad
[14:27] <tjaalton> ah
[14:27] <tjaalton> still getting 'fatal: Could not read from remote repository.' for some kernel repos
[14:27] <tjaalton> but I'll wait if it'll settle down
[14:28] <cjwatson> Might be a bit overloaded since it's trying to page stuff back in
[14:29] <cjwatson> My clones of LP itself are going super-slowly
[14:29] <cjwatson> Oh, and it's recipe-o-clock, one moment
[14:30] <tjaalton> worked this time
[14:30] <cjwatson> Cancelling some recipe builds which should help as well
[15:44] <ali1234> what is the difference between binutils and binutils-multiarch?
[15:49] <ali1234> i am trying to build a cross-toolchain that targets debian-style multiarch
[15:52] <ali1234> i built gcc with --enable-multiarch but then when linking, this happens: https://paste.ubuntu.com/p/bBcJJDhphC/
[15:52] <ali1234> strace output at the bottom shows tha binutils is not searching the multiarch paths, ie it searches $SYSROOT/lib but not $SYSROOT/lib/arm-linux-gnueabihf
[15:57] <ali1234> so my question is what do i need to do to binutils to make this work?
[15:57] <ali1234> i assume it is something done at build time due to the existence of the two binutils packages
[16:00] <ali1234> i see in debianrules it is configured with "--libdir=/$(PF)/lib/$(DEB_HOST_MULTIARCH)" - i should probably do something like that?
[16:13] <ali1234> or maybe 129_multiarch_libpath.patch is the key?
[17:42] <tjaalton> ahasenack: sssd 2.2.2 in debian, btw
[17:43] <ahasenack> yeah, but FF :(
[17:44] <rafaeldtinoco> ali1234: https://wiki.debian.org/Multiarch/HOWTO
[17:44] <rafaeldtinoco> might help you
[17:45] <rafaeldtinoco> and https://wiki.debian.org/CrossToolchains
[17:56] <ali1234> already read it.it doesn't explain what debian did to binutils
[18:38] <rafaeldtinoco> ali1234: well, without too much of reading (output) id say your linker (for another arch) can't find the libs (made for that arch)
[18:38] <ali1234> nope
[18:39] <rafaeldtinoco> if it was run time the variable LD_LIBRARY_PATH would be the one checked by the linker (statically set in the ELF) and check for the shared libraries etc
[18:39] <ali1234> the problem is my linker doesnt have 129_multiarch_libpath.patch which makes it search the multiarch directories
[18:39] <rafaeldtinoco> since this is link time, I think LIBRARY_PATH only is the env variable you would need
[18:39] <rafaeldtinoco> but I prefer doing that inside lxc containers using qemu-user-static
[18:39] <ali1234> what i dont understand is why gcc has multiarch support upstream but binutils needs a patch
[18:39] <rafaeldtinoco> ali1234: great.
[18:40] <ali1234> and also i don't know how to apply the required patch because i am building the toolchain with abe
[18:40] <ali1234> and also i don't know if there are other patches required in other tools
[18:40] <rafaeldtinoco> ali1234: you can open a bug to the package in question
[18:40] <rafaeldtinoco> and suggest the patch
[18:40] <rafaeldtinoco> and explain how to reproduce in a simple example
[18:40] <ali1234> what, binutils upstream?
[18:40] <rafaeldtinoco> so someone else can merge it
[18:41] <ali1234> i kind of assumed that it had already been proposed, i mean that patch has been around for as long as multiarch
[18:41] <ali1234> so like 10+ years
[18:41] <ali1234> i kind of figured there's a reason it hasn't been merged upstream
[18:42] <ali1234> also you can't reproduce it in a simple example - it requires that you have a multiarch compiler and multiarch libs installed
[18:42] <rafaeldtinoco> ali1234: https://wiki.dlang.org/GDC/Cross_Compiler/Existing_Sysroot
[18:42] <ali1234> yes, that
[18:43] <rafaeldtinoco> gives as example doko's url on that patch
[18:43] <rafaeldtinoco> http://bazaar.launchpad.net/~doko/binutils/pkg-2.24-debian/view/head:/patches/129_multiarch_libpath.patch
[18:43] <ali1234> yes
[18:43] <ali1234> so then that seems to indicate that it is only that one patch required
[18:44] <ali1234> there is a mistake in those instructions though - they don't build gcc with --enable-multiarch so they will have the exact opposite problem that i have
[18:44] <ali1234> binutils supports multiarch but gcc doesn't
[18:45] <rafaeldtinoco> yep, when debugging readelf has to be the binary for the arch being debugged
[18:45] <ali1234> i get the feeling that there are no more than 5 people in the whole world who actually understand the problem :(
[18:45] <rafaeldtinoco> as multiarch is not compiled
[18:46] <rafaeldtinoco> just 1 example ^
[18:46] <ali1234> i don't know what that means
[18:46] <ali1234> gcc has a configure switch "--enable-multiarch" which appends the extra directories to the search path. identical to what the patch does for binutils. except it is in the upstream source
[18:47] <ali1234> if you don't turn it on, then gcc won't be able to find your libs
[18:47] <ali1234> if you don't patch binutils then it wont be able to find your libs
[18:47] <ali1234> so you need both, or neither
[18:48] <ali1234> it doesn't even really have anything to do with architectures, it is just that the libraries are in a different directory to normal
[18:48] <rafaeldtinoco> ali1234: arent u mixing up multiarch term with cross compiling ?
[18:48] <ali1234> you can have this problem with a native compiler
[18:48] <ali1234> no, i'm not
[18:49] <ali1234> they are two different things
[18:49] <rafaeldtinoco> i know they are =)
[18:49] <ali1234> you can have a native multiarch compiler
[18:49] <ali1234> multiarch just means that libs are in /lib/$arch-triplet instead of /libs and this means all search paaths have to be adjusted, or your compiler will not be able to find anything
[18:49] <rafaeldtinoco> right
[18:50] <ali1234> so my pain point is that the support for this exists upstream in gcc and enabling it is a compile time switch, but for binutils you have to apply a patch
[18:50] <ali1234> which seems insane given how closely related they are. you would think they'd both have it
[18:50] <rafaeldtinoco> I see what you mean now
[18:51] <ali1234> if you have a system where one of them supports it and the other doesn't, you will have a bad time
[18:52] <rafaeldtinoco> ali1234: when you say binutils, you mean only ld ?
[18:52] <rafaeldtinoco> or all binaries ?
[18:52] <ali1234> well the atch applies to the binutils source
[18:52] <ali1234> it only seems to touch ld and gold
[18:52] <ali1234> but binutils is binutils
[18:53] <rafaeldtinoco> this page covers lots of stuff about this:
[18:53] <rafaeldtinoco> https://wiki.debian.org/Multiarch/LibraryPathOverview
[18:54] <rafaeldtinoco> This requires modifications to glibc's ld.so loader (can possibly be provided via platform back-end changes). Backwards compatibility most likely requires that both the new multiarch location and the old location are searched.
[18:54] <rafaeldtinoco> According to the primary multiarch assumption, the system library search paths are modified to include the multiarch target string:
[18:54] <ali1234> sure. i'm not compiling glibc though
[18:54] <rafaeldtinoco> its the same case though
[18:54] <ali1234> yes
[18:54] <rafaeldtinoco> its basically saying you will have a problem with the linker
[18:55] <rafaeldtinoco> depending on LIBRARY_PATH
[18:55] <ali1234> ld.so, yes, but i'm not compiling that either
[18:55] <ali1234> i'm trying to make a toolchain that targets an existing debian sysroot
[18:55] <rafaeldtinoco> i see, for it to coexist
[18:55] <ali1234> so it already has all the runtime stuff
[18:56] <rafaeldtinoco> so you can generate armhf packages lets say
[18:56] <ali1234> right, and link against packaged libraries that already exist
[18:56] <rafaeldtinoco> using the second toolchain (cross compiling)
[18:56] <rafaeldtinoco> etc
[18:56] <ali1234> exactly
[18:56] <rafaeldtinoco> yep , i used to work @ linaro
[18:56] <rafaeldtinoco> i used armhf containers for that
[18:56] <rafaeldtinoco> or arm64
[18:56] <rafaeldtinoco> etc
[18:56] <ali1234> containers are so slow though
[18:56] <rafaeldtinoco> its a good idea
[18:56] <ali1234> this is for raspbian
[18:56] <rafaeldtinoco> yep, depending on qemu-user-static isnt good
[18:56] <ali1234> linaro bootstrapped their original cross compiler
[18:56] <rafaeldtinoco> because its not multi threaded also
[18:57] <ali1234> but it's now horribly out of date, and nobody at rpi-foundation knows how to make a new one
[18:57] <rafaeldtinoco> gotcha
[18:57] <rafaeldtinoco> ali1234: and why gcc6 ?
[18:57] <ali1234> not gcc6
[18:57] <rafaeldtinoco> not 6 from your output ?
[18:57] <ali1234> ive been working on this for literally years
[18:58] <ali1234> gcc6 was the default for raspbian stretch
[18:58] <rafaeldtinoco> gcc version 6.4.1 20180425 [linaro-6.4-2018.05 revision 7b15d0869c096fe39603ad63dc19ab7cf035eb70] (Linaro GCC 6.4-2018.05)
[18:58] <rafaeldtinoco> gotcha
[18:58] <ali1234> but i want to be able to target current raspbian, which is 8.3
[18:58] <ali1234> and then whatever the next one is... and so on
[18:58] <rafaeldtinoco> so your will at the end is to cross compile
[18:58] <rafaeldtinoco> all raspbian
[18:58] <ali1234> yes
[18:58] <rafaeldtinoco> in a fast way
[18:59] <ali1234> no
[18:59] <rafaeldtinoco> so you dont depend on actual hw ?
[18:59] <ali1234> i dont want to cross compile anything that already exists in raspbian
[18:59] <rafaeldtinoco> or to have multiple toolchains
[18:59] <ali1234> i want to cross compile things that don't exist in raspbian, using the raspbian libraries that do exist
[18:59] <rafaeldtinoco> hum. i see
[19:00] <ali1234> compiling raspbian itself ain't my problem. afaik they have some arm servers to do it
[19:00] <rafaeldtinoco> yep
[19:00] <rafaeldtinoco> i was about to point you https://www.socionext.com/en/products/assp/SynQuacer/Edge/
[19:00] <rafaeldtinoco> but as you said, its likely something to allow others as well
[19:00] <rafaeldtinoco> to contribute generating new packages
[19:01] <rafaeldtinoco> without having necessarily the arch
[19:01] <ali1234> yeah i bet that is still slower than cross compiling
[19:01] <rafaeldtinoco> its not =)
[19:01] <rafaeldtinoco> Linux firewall 5.0.0-30-generic #32-Ubuntu SMP Wed Sep 18 00:24:43 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
[19:01] <rafaeldtinoco> $ nproc
[19:01] <rafaeldtinoco> 24
[19:01] <rafaeldtinoco> its not super fast
[19:01] <rafaeldtinoco> but its ok
[19:01] <ali1234> how much does it cost?
[19:02] <rafaeldtinoco> ~ $1k
[19:02] <rafaeldtinoco> 1.2k i suppose
[19:02] <ali1234> hmm that's actually kind of reasonable for 24 core
[19:02] <rafaeldtinoco> ARMv8 rev 1
[19:02] <rafaeldtinoco> you can run armhf kvm guests
[19:02] <rafaeldtinoco> or lxd guests
[19:02] <rafaeldtinoco> like I do
[19:02] <rafaeldtinoco> I do ubuntu armhf/arm64 debugs on that machine
[19:02] <rafaeldtinoco> actually
[19:02] <ali1234> still, the lack of cross compiler annoys me, and i'm not the only one
[19:02] <rafaeldtinoco> yep yep
[19:03] <rafaeldtinoco> orthogonal things
[19:03] <rafaeldtinoco> just for you to have in mind ^
[19:03] <ali1234> so the problem i have now is that i built the compiler i have now with linaro abe
[19:04] <ogra> just get a Pi4 4GB, a fast USB3 SSD and be done ... my builds on that HW run as fast/slow as on launchpad
[19:04] <ali1234> lol, launchpad is really slow
[19:04] <ogra> i have seen and done slower arm builds :)
[19:04] <ali1234> anyway, abe lets you set gcc configure options (and binutils configure options) so i was able to enable multiarch for gcc, cos it is upstream. but it has no way to apply a patch to binutils
[19:05]  * ogra did the original ubuntu arm port bootstrapping on an nslu2 ;)
[19:05] <rafaeldtinoco> ogra: #) =)
[19:05] <ali1234> how many times did you have to run "make" before it worked?
[19:06]  * rafaeldtinoco gets back to eoan installer problem
[19:06] <rafaeldtinoco> as BETA is broken
[19:06] <ogra> endless times :)
[19:06] <rafaeldtinoco> ali1234: let me know your findings
[19:06] <ogra> not many people know though that we actually supported ARMv5 for one release
[19:06] <ogra> (jaunty IIRC)
[19:22] <ali1234> okay a question: the binutils-source package: is the tarball inside it pre-patched?
[19:22] <ali1234> same question for gcc-8-source
[19:23] <sarnold> ali1234: if the tarball name includes 'dfsg' in it, that's a clear sign that it has been; otherwise it's harder to tell
[19:25] <ali1234> i'm not talking about the source package
[19:25] <sarnold> ahhhhhh
[19:25] <ali1234> binutils-source is a "binary" package that installs /usr/src/binutils/binutils-2.31.1.tar.xz
[19:26] <ali1234> (or whatever version)
[19:30] <ali1234> thing is... it also installs a "patches" subdir so i am wondering if i need to apply those manually?
[19:31] <rafaeldtinoco> ali1234: you should read a bit about debian packaging
[19:31] <ali1234> this isn't a source package >.<
[19:31] <rafaeldtinoco> ah
[19:31] <rafaeldtinoco> lol
[19:31] <rafaeldtinoco> ok
[19:31] <rafaeldtinoco> :P
[19:51] <blackboxsw> Hey folks, I've got a package postinst script that takes certain cleanup actions based on determining the Ubuntu series based on contents  of /etc/os-release.    If a system is performing a do_release_upgrade, can we rely on etc/os-release to contain the target series when a new series package is upgraded?
[19:51] <blackboxsw> I am presuming that /etc/os-release would be updated to the target "upgraded" ubuntu release name/content prior to upgrading to the packages for that release because packaging may have release-specific configuration behavior. So, for our postinst scripts, we're going to assume the upgraded xenial content is present in /etc/os-release prior to upgrading to any of the other xenial deb packages.
[19:51] <blackboxsw> *do-release-upgrade* rather
[19:54] <blackboxsw> Is that the correct assumption that /etc/os-release will be present during a do-release-upgrade before upgrading 3rd party debs? Or is there a potential race we need to worry about.
[19:55] <ali1234> what if /etc/os-release is updated but nothing else on the system is?
[19:55] <sarnold> blackboxsw: I believe if you need to go this route, you'll need to declare Pre-Depends: checks https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
[19:56] <sarnold> blackboxsw: those tend to add brittleness though so it'd probably be worth exploring alternatives further
[19:57] <blackboxsw> sarnold: in our case, and alternative would be for our postinst to look at the previous package version $2 when running "configure" an 'know' that it came from a different series during an upgrade path. So, we could explore that as an option
[19:58] <blackboxsw> then our new package would know it's upgrading across a release
[19:58] <sarnold> blackboxsw: at least there's loads of those in the archive to crib off of :) it's a bit more effort to keep track of the allowed upgrade paths, but feels more likely to be reliable to me
[19:58] <blackboxsw> ali1234: in our case, we have only package-specific config changes that are made based on values in /etc/os-release. So, no external dependencies beyond that
[19:59] <blackboxsw> thanks for the suggestions
[19:59] <ali1234> well, why do you need to know the release at install time then?
[20:03] <ali1234> or are you just trying to figure out that the release has changed?
[20:56] <Unit193> If anyone cares about wayland and wxgtk, https://packages.qa.debian.org/w/wxwidgets3.0/news/20191002T204524Z.html fixes two-finger touchpad scrolling.
[20:58] <Unit193> https://salsa.debian.org/freewx-team/wx/commit/9fe0c523faa50746099444ed7b50fccf7bbda136.patch is actually surprisingly small..
[21:23] <chiluk> is anyone going to KubeCon ? I'd love to catch up with some of my old ubuntu peoples.
[21:34] <ahasenack> hm, I have a postinst calling gpg, and am wondering if I should add gpg (or gnupg) to d/control's Depends
[21:34] <ahasenack> the package is flagged as optional in bionic
[21:34] <ahasenack> and important on trusty
[21:38] <ahasenack> haven't seen a system without /usr/bin/gpg, but looks like it's possible
[22:08] <infinity> ahasenack: apt-cache show gnupg | grep ^Essential
[22:08] <infinity> ahasenack: If that doesn't return anything (compare to, say, "apt-cache show coreutils | grep ^Essential"), then you need a dependency.
[22:08] <infinity> ahasenack: Relying on "I think most people have this installed" isn't the way to go. :)
[22:09] <ahasenack> yep, I'm adding it, I checked Priority before
[22:09] <ahasenack> and there is no "Essential" as you said
[23:17] <mwhudson> some gpgv* is guaranteed to be there
[23:17] <mwhudson> because apt
[23:17] <mwhudson> but not everything
[23:18] <Unit193> Package: gpgv, Priority: important, Build-Essential: yes.  So it's somewhat important, one might say.
[23:19] <Unit193> (Note that you really should still depend on it, if you need it, though.)


[04:23] <BWMerlin> has anyone used lubutu as a NAS and or a home theatre pc?
[11:27] <kosaidpo|> hello guys
[11:27] <MrChrisDruif> Hai kosaidpo|, how did the removal of Windows go?
[11:27] <kosaidpo|> didnt do it yet : D
[11:28] <kosaidpo|> hows you MrChrisDruif
[11:28] <MrChrisDruif> Pretty good, just had breakfast....at noon :P
[11:28] <kosaidpo|> haaha cool
[11:29] <kosaidpo|> any idea how to make gbrainy in french i got it installed in eng :P
[11:31] <MrChrisDruif> Install French? :P
[11:32] <kosaidpo|> my system is in french but whtn i installed it did in eng :P
[11:33] <MrChrisDruif> Weird
[11:33] <kosaidpo|> i mean have its Gui and all in french
[11:33] <MrChrisDruif> Maybe it's not translated?
[11:34] <kosaidpo|> no it is i had it b4 in french
[11:35] <MrChrisDruif> Weird....<_<"
[11:36] <kosaidpo|> MrChrisDruif:  : D
[12:04] <ubuntu_> hello
[12:04] <MrChrisDruif> Hai bilal03
[12:04] <bilal03> MrChrisDruif> i habe got a problem with my dpkg
[12:04] <bilal03> MrChrisDruif> i have got a problem with my dpkg
[12:05] <MrChrisDruif> Not nice
[12:05] <MrChrisDruif> What is it saying?
[12:05] <bilal03> when i try to install something via apt-get i got this error messagedpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
[12:06] <bilal03> after running this 'sudo dpkg --configure -a' i got this one
[12:06] <bilal03> ubuntu@ubuntu:~$ sudo dpkg --configure -a
[12:06] <bilal03> dpkg: parse error, in file '/var/lib/dpkg/updates/0021' near line 0:
[12:06] <bilal03>  newline in field name `#padding'
[12:06] <MrChrisDruif> And you did?
[12:14] <bilal03> yes i did and got the error
[12:15] <bilal03> ubuntu@ubuntu:~$ sudo dpkg --configure -a dpkg: parse error, in file '/var/lib/dpkg/updates/0021' near line 0:
[12:15] <bilal03> anybody know how to fix it?
[12:41] <bilal03> hello
[12:42] <bilal03> anybody for help
[12:44] <bilal03> i got problem with dpkg http://paste.ubuntu.com/594806/
[18:35] <azzurra> alguien habla español
[18:53] <bioterror> azzurra, sowwy, english only
[19:21] <home-alone> lubuntu 10.10 is no more light weight what is point of installing it now...???
[19:23] <bioterror> what are you after
[19:24] <MrChrisDruif> Lubuntu 10.10 not lightweight?
[19:26] <Unit193> Well, the point of Lubuntu is to be a full system... not just to be lightweight (thus it's not as lightweight as some others)
[19:26] <bioterror> :D
[19:27] <bioterror> best way to troll is join a channel, say something and then disconnect modem from wall
[19:27] <bioterror> "I didnt fake my quit" ;D
[19:33] <bioterror> home-alone, would you like to explain more
[19:33] <bioterror> what's not lightweight, what's the issue and so on
[19:35] <MrChrisDruif> Indeed
[19:39] <home-alone> well i used  10.04 on very old hardware and it worked like charm but 10.10 is less or more as heavy as ubuntu
[19:40] <bioterror> how's that possible, as software has been tested a lot
[19:41] <MrChrisDruif> bioterror: kernel? Or wouldn't it even install if it was due to i585 support removal?
[19:42] <bioterror> yes
[19:42] <MrChrisDruif> It wouldn't install you mean?
[19:43] <bioterror> like 64bit image says on 32bit system, Aint gonna work
[19:43] <home-alone> i installed but took a long time and running slow
[19:47] <bioterror> home-alone, what are the specs
[19:48] <home-alone> pentioum III 256 ram
[19:49] <home-alone> so i am using debian 6 which is running fine with even gnome
[19:49] <bioterror> theres lots of different kind of Pentium III's. for example Tualatin
[19:51] <home-alone> its P III ghz
[19:51] <home-alone> 1 ghz
[19:51] <bioterror> that's not even slowest cpu of that line
[19:52] <bioterror> I think it might be related to kernel
[19:52] <home-alone> debian 6 with gnome is fine with the specs
[19:58] <bioterror> that's weird
[20:00] <home-alone> how that weired...??
[20:02] <bioterror> becouse it is
[20:03] <home-alone> yes it is .
[20:03] <MrChrisDruif> LXDE should run fine on that if I remember right
[20:04] <home-alone> yes thats wonder me lxde is much lighter thhan gnome
[20:05] <MrChrisDruif> That's the whole idea of LXDE (Lightweight X11 Desktop Environment)
[23:45] <kavurt> is lubuntu good enough?
[23:47] <szczur> lubuntu is awesome :)
[23:48] <MrChrisDruif> kavurt: That is something only you can answer :)
[23:50] <kavurt> MrChrisDruif: if i install it, does it install grub perfectly, and find my ubuntu and win oss?
[23:50] <MrChrisDruif> It should :)
[23:50] <MrChrisDruif> But I'll won't promise anything :D
[23:50] <kavurt> i see
[23:56] <Unit193> If it doesn't, you can use os-prober


[12:11] <Tonio_> Mithrandir: I'mm make a point and eventually reping you on monday if there is no other package accepted in the archives :)
[12:11] <Tonio_> s/mm/ll
[12:11] <Tonio_> Mithrandir: probably another package accepted, since there is no reason to reject this appart from that
[12:12] <Tonio_> Mithrandir: the only thing I changed is add missing builddep to fix ftbfs
[12:13] <BenC> superm1: Don't rev the changelog
[12:13] <superm1> Benc, I saw https://wiki.ubuntu.com/KernelCustomBuild?highlight=%28kernel%29 after pinging you
[12:13] <BenC> superm1: Your patch should not touch anything in debian/* (at least what you send me shouldn't)
[12:13] <superm1> i'm building that way locally
[12:13] <BenC> no need, that's meant for people who want to keep their changes even after an update from the repo
[12:14] <superm1> oh?
[12:14] <BenC> s/repo/archive/
[12:14] <superm1> well whats the appropriate way to make sure this patch builds right then?
[12:14] <BenC> superm1: the parts to change the changelog are for when you don't want ubuntu kernels to overwrite your own
[12:14] <BenC> superm1: apply patch, "fakeroot debian/rules binary-debs flavours=generic"
[12:15] <superm1> okay thats what i was doing
[12:19] <superm1> BenC, and if the build fails, is there an easy way for me to make it pick back up where it left off after fixing the file?  (hasn't gotten to the ubuntu/* directory yet, but in case it does)
[12:20] <superm1> i'd imagine debian/rules binary-debs calls debian/rules clean first
[12:35] <glick> hi
[12:38] <Hobbsee> mpt: +1 at the suggestion to remove the "report a bug" option.  although kde does it.
[12:39] <mpt> Hobbsee, oh, I got moderated through to ubuntu-devel@? yay
[12:41] <Hobbsee> mpt: seems so.  if you only sent it to -devel that is
[12:41] <Hobbsee> yep, you did
[12:41] <glick> hey can anyone recommend any reading for someone wanting to get started in kernel devel?
[12:42] <Hobbsee> glick: probably ask someone like BenC or look on the wiki
[12:42] <Hobbsee> not sure where exactly, as i dont do kernel stuff
[12:42] <Hobbsee> or see #ubuntu-kernel
[12:42] <glick> hmm thanks
[12:42] <glick> whose BenC ?
[12:42] <mpt> Ben Collins, Ubuntu kernel maintainer
[12:43] <glick> cool
[12:45] <Fujitsu> mpt: We haven't had a whole lot of bugs from the menu option yet...  The 'have-nots' nobody to blame.
[12:50] <Fujitsu> Well, actually, not really. We already have 25000 bugs open now, a few thousand extra won't make a difference.
[05:47] <Burgundavia> keescook: you around?
[06:27] <benb> where is the best place to read about becoming a developer for ubuntu?
[06:28] <benb> note to self...  read the topic
[06:40] <sladen> benb: :)  Yup, and hit the wiki (google for  ubuntu motu)
[06:57] <NoSense> hi
[06:57] <NoSense> my ps/2 doesn't work in feisty fawn beta
[06:58] <NoSense> ihave only upgraded from edgy
[06:58] <Fujitsu> This isn't a support channel, NoSense. Try #ubuntu+1
[06:58] <NoSense> thanks, but it can be a bug
[07:04] <bluefoxicy> oh
[07:04] <bluefoxicy> the ps/2 thing is probably.. no, nevermind.  It's not that.
[07:06] <bluefoxicy> been meaning to mention that but haven't gotten around to it.  Anyway.
[08:01] <desrt> nice to see the archive grind to a halt as feisty beta gets dugg :)
[08:06] <Burgundavia> heh
[08:07] <Fujitsu> Hehe, it'd be nice to have traffic graphs around releases.
[08:10] <jhernandez> Hi :)
[08:12] <jhernandez> I have a problem with my deb package, all my files are installed in / directory.
[08:42] <Admiral_Chicago> can someone point me to the bazaar branch for apport?
[08:43] <Admiral_Chicago> wait, google did
[11:18] <zyga> hello
[12:41] <doko> Mithrandir: please could you requeue glibc/amd64 on another buildd? the build failure is unreproducible on ronne
[12:41] <eternalswd> Just wondering about coreutils version numbers.  Feisty has 5.97 as it's package version but the most recent stable version available at the gnu site is 6.9  Is this just a version numbering issue where ubuntu numbers it differently, or is that particular package really that far behind?
[12:46] <Mithrandir> doko: no, it's a kernel limitation; fix scripts/check-local-headers.sh to use xargs.
[12:47] <doko> Mithrandir: so why do we have to make such changes during release phases? ...
[12:48] <Mithrandir> doko: I have no control over which kernel the buildds run.
[12:48] <Mithrandir> doko: also, it seems it died of inactivity.  It was probably hung.
[12:49] <doko> Mithrandir: correct, the scripts/check-local-headers.sh is unrelated; it's a parallel build.
[12:50] <Mithrandir> doko: but that's an error too. :-P
[12:51] <Mithrandir> (and should be fixed)
[12:53] <doko> Mithrandir: maybe, but it's not the cause for the build failure
[12:56] <doko> Mithrandir: please requeue to check if the timeout is showing up on another buildd
[02:32] <Hobbsee> Mithrandir, or any other archive admin, when you have time/inclination, could you shove the rest of the beryl stuff?  i think it's in binary NEW, and i'm wondering how much crack's in it.
[02:40] <Mithrandir> Hobbsee: doing so already
[02:40] <Hobbsee> Mithrandir: thanks :)
[02:40] <Mithrandir> (-:
[02:42] <racarr> Thanks
[02:51] <Hobbsee> Mithrandir: any chance you could push through kuickshow as well please?  :)
[02:51] <ajmitch> you're asking for a lot today
[02:51] <Hobbsee> ajmitch: yes, i'm mean, like that.
[02:52] <ajmitch> heh :)
[02:53] <tsmithe> Mithrandir, do you know why wired was rejected?
[02:59] <Mithrandir> tsmithe: no, the uploader should have been mailed by the archive admin doing the rejection.  I can ask who did it tomorrow.
[02:59] <Mithrandir> Hobbsee: already done.
[03:00] <tsmithe> Mithrandir, cheers.
[03:00] <tsmithe> Adri2000 should have been pinged, but he's been away for a while
[03:01] <Hobbsee> Mithrandir: great, thanks :)
[03:35] <tsmithe> Mithrandir, do you know of any case where that mail would not get sent. it would seem Adri2000 got nothing
[03:36] <tsmithe> (he uploaded ubuntu2, but both ubuntu1 and ubuntu2 were rejected)
[03:36] <Mithrandir> tsmithe: usually to the uploader, with a Cc to ubuntu-archive, but given that it didn't happen this time it was either a mistake (reject instead of accept) or the admin forgot
[03:37] <tsmithe> hrrmh
[03:37] <cjwatson> tsmithe: pitti sent a mail to you about it
[03:37] <cjwatson> Date: Fri, 23 Mar 2007 15:35:45 +0100
[03:37] <cjwatson> From: Martin Pitt<EMAIL_ADDRESS>[03:37] <cjwatson> To: Toby Smithe<EMAIL_ADDRESS>[03:37] <cjwatson> Subject: Rejecting wired
[03:37] <cjwatson> Message-ID<EMAIL_ADDRESS>[03:38] <tsmithe> really... i received nothing, or at least i thought i received nothing
[03:38] <Adri2000> tsmithe: look into your gmail spam ;)
[03:38] <cjwatson> check your spam bin
[03:38] <tsmithe> i'll have a look again
[03:39] <tsmithe> thanks
[03:45] <tsmithe> cjwatson, i don't seem to have it anywhere, which is annoying
[03:47] <tsmithe> hmm so pdf files are a no-no
[03:47] <tsmithe> if i get want to get it included now, i'll need an exception, right?
[03:48] <cjwatson> only PDF files without source
[03:48] <tsmithe> yes
[04:36] <mjg59> Is anyone here using the wistron_btns driver?
[04:48] <ivoks> mjg59: umm... synaptics is now almost useless... :/
[04:50] <mjg59> ivoks: How so, and on what hardware?
[04:50] <ivoks> mjg59: i was just going to LP and provide info
[04:50] <mjg59> Feel free to just let me know here
[04:51] <ivoks> mjg59: scroll is slow; i have to seep finger two-three times to scroll like one can scroll with arrow-pad
[04:52] <mjg59> ivoks: scroll as in horizontal and vertical scrolling, rather than scroll as in moving the pointer across the screen, right?
[04:52] <mjg59> Is this a synaptics device or an alps one?
[04:52] <ivoks> mjg59: vertical
[04:54] <ivoks> mjg59: alps
[04:54] <mjg59> Ok.
[04:54] <ivoks> AlpsPS/2 ALPS GlidePoint
[04:55] <mjg59> Ah, I suck
[04:56] <mjg59> Hang on, let me build you a test package
[04:57] <ivoks> man, you don't suck
[04:57] <ivoks> :)
[04:58] <mjg59> ivoks: http://www.codon.org.uk/~mjg59/tmp/xserver-xorg-input-synaptics_0.14.6-0ubuntu7_i386.deb
[04:58] <mjg59> ivoks: Install that, restart X and then let me know if it works any better?
[04:58] <ivoks> ok
[04:59] <mjg59> I think I just got a couple of calculations the wrong way round
[04:59] <ivoks> brb
[05:01] <ivoks> mjg59: it's faster, but not like it use to be :)
[05:01] <mjg59> ivoks: Ok, it's arguably correct now and slightly broken in the past :)
[05:01] <ivoks> if you say so :)
[05:02] <mjg59> The default speeds should now be the same regardless of what sort of pad you have - before, it varied depending on whether it was an Apple, ALPS or Synaptics device
[05:02] <mjg59> If you think it's too slow, I can bump it up slightly?
[05:02] <ivoks> maybe other users should give feedback too
[05:03] <tepsipakki> there are bug reports on synaptics :)
[05:03] <ivoks> :)
[05:04] <mjg59> Hrm.
[05:04] <mjg59> Yeah, previously alps was set much faster than synaptics
[05:04] <mjg59> They should now both be much the same
[05:04] <ivoks> before, i would sweep my finger and it would scroll all the way, to the end
[05:04] <mjg59> Oh, hm.
[05:05] <ivoks> now i have to sweep 4-5 times
[05:05] <mjg59> No, maybe I've still screwed up.
[05:05] <ivoks> take your time...
[05:06] <mjg59> ivoks: Can you re-download the same package, install it again and restart X again?
[05:06] <ivoks> sure
[05:07] <ivoks> brb
[05:10] <mjg59> tepsipakki: Seen 95253?
[05:10] <tepsipakki> mjg59: yes
[05:11] <tepsipakki> I guess..
[05:11] <ivoks> great! even better than before :)
[05:11] <mjg59> ivoks: Super
[05:12] <ivoks> my hero :D
[05:12] <mjg59> tepsipakki: Also, if we're setting defaults for synaptics, it should probably be done in the driver rather than xorg.conf
[05:13] <tepsipakki> oh wait, that's an intel machine and not powerpc.. attach your 'lspci -vvnn' to that
[05:14] <mjg59> tepsipakki: It's using vesa, which is correct
[05:14] <mjg59> The issue is that there's no useful values in the monitor section
[05:15] <tepsipakki> are there any values written?
[05:15] <mjg59> For hsync and vertrefresh? No
[05:15] <tepsipakki> so it needs an exception in xserver-xorg.postinst
[05:16] <tepsipakki> that's what the lspci is for ;)
[05:16] <tepsipakki> -log
[05:16] <mjg59> I don't think I understand. Why would it be an issue with this specific machine?
[05:16] <tepsipakki> err, output
[05:16] <mjg59> Rather than all of them using vesa?
[05:16] <tepsipakki> look at the postinst..
[05:16] <tepsipakki> there are exceptions all over the place
[05:17] <mjg59> I can't find any vesa-related exceptions...
[05:18] <andre_pl> very sorry to intrude in the devel channel, but i'm having a showstopper of a problem and nobody else can help.  every time I reboot my laptop the nvidia kernel module is gone. the file doesn't exist in /lib/modules and I have to uninstall and reinstall the nvidia-glx and linux-restricted-moudles package to get X to start... then if I reboot again, same deal.
[05:19] <tepsipakki> mjg59: not yet anyway :P
[05:19] <mjg59> tepsipakki: Sorry, I'm really not understanding this at all. Why do you think it's something that's specific to this machine, rather than an issue affecting everything using the vesa driver?
[05:19] <tepsipakki> when did it work?
[05:19] <mjg59> Worked fine in edgy
[05:19] <mjg59> andre_pl: Please file a bug at launchpad.net
[05:20] <ivoks> andre_pl: i've seen that...
[05:20] <andre_pl> mjg59: i intend to as soon as I can get to a browser thats a little more useful than links
[05:20] <ivoks> andre_pl: is that amd64 version?
[05:20] <mjg59> andre_pl: Also, make sure you have linux-restricted-modules-common installed
[05:20] <andre_pl> ivoks: no, its the generic kernel
[05:20] <ivoks> andre_pl: so... 32bit version of ubuntu?
[05:20] <mjg59> tepsipakki: I haven't been updating this machine religiously - the previous install on it was fesity, but pre-7.2 transition
[05:21] <andre_pl> ivoks: yes.
[05:21] <tepsipakki> mjg59: and it worked with pre-7.2?
[05:22] <andre_pl> mjg59: linux-restricted-modules-common is installed
[05:22] <mjg59> tepsipakki: I believe so, yes
[05:22] <ivoks> andre_pl: sudo apt-get --reinstall install linux-restricted-modules-`uname -r`
[05:23] <tepsipakki> mjg59: could you attach Xorg.0.log from a non-working and a working X to that bug
[05:24] <andre_pl> ivoks: just waiting for it to finish removing the 386 modules.  why do they get pulled in along with the generics?
[05:24] <mjg59> tepsipakki: Not trivially, due to the breakage in casper that leaves me with no consoles
[05:24] <mjg59> tepsipakki: I'll see what I can do
[05:25] <tepsipakki> mjg59: thanks, hopefully we'll get somewhere
[05:25] <tepsipakki> the vesa driver was updated 1.2.1 -> 1.3.0 post herd5
[05:26] <ivoks> andre_pl: cause you didn't install linux-generic first
[05:26] <tepsipakki> mjg59: what chip does it have?
[05:26] <andre_pl> ivoks: I'll have to try that.  first priority is figuring out why this driver keeps disappearing though.
[05:26] <mjg59> r500
[05:27] <tepsipakki> http://librarian.launchpad.net/6772731/vesa-1.3.0-range-hack.patch
[05:27] <tepsipakki> that's included in the latest version, it's from fedora and it was specifically meant for r5xx
[05:27] <Ubugtu> Announcement from my owner (Seveas): ubugtu will be taken offline and integrated with ubotu - epect some downtime
[05:29] <tepsipakki> mjg59: see bug #89853
[05:43] <mjg59> tepsipakki: That's a post-beta upload?
[05:44] <tepsipakki> nope
[05:44] <tepsipakki> hmm
[05:44] <tepsipakki> check your version
[05:44] <cr3> in casper, what creates /dev/loop0? I see that the loop module is being loaded and /sys/block/loop0 is created, but still no /dev entry :(
[05:47] <tepsipakki> oh
[05:47] <tepsipakki> "published 2007-03-24"
[05:48] <tepsipakki> so it wasn't in beta
[05:49] <tepsipakki> ..and now I see the acceptance mail from yesterday :)
[05:49] <mjg59> tepsipakki: Haha
[05:49] <mjg59> tepsipakki: Ok, sounds good
[05:50] <tepsipakki> mjg59: I'll just mark your bug as a dupe of that other one
[05:50] <mjg59> tepsipakki: Sounds good
[05:51] <tepsipakki> I have another vesa upload waiting, and that should make it perform better and fix a potential crash with randr
[06:37] <imbrandon> Mithrandir, ping ( beryl-plugins , source universe / binary main !? )
[06:37] <imbrandon> is that a booboo
[06:37] <imbrandon> brandon@hood:~$ sudo apt-cache madison beryl-plugins
[06:37] <imbrandon> beryl-plugins | 0.2.1-0ubuntu2 | http://archive.ubuntu.com feisty/main Packages
[06:37] <imbrandon> beryl-plugins | 0.2.1-0ubuntu2 | http://archive.ubuntu.com feisty/universe Sources
[06:41] <racarr> Small 'booboo'
[06:49] <mjg59> Anyone here using the acerhk driver?
[07:22] <zyga> anyone here has access to a mirror of all packages?
[07:22] <zyga> main + restricted + universe + multiverse?
[07:23] <shawarma> Er... Everyone has? They're public.
[07:23] <zyga> shawarma: I mean like on their filesystem with fast access?
[07:24] <shawarma> zyga: Ah.. No. Why?
[07:24] <zyga> shawarma: due to the inclusion of command-not-found into main I got some bugs to squash and I need my dataset
[07:24] <zyga> previously I mirrored everything but I'm not that bold now :P
[07:25] <zyga> (AFAIR it's about 50GB)
[07:25] <Seveas> zyga, more than doubled now :)
[07:25] <zyga> now I have a slightly better infrastructure so I can scan here and process there
[07:25] <shawarma> zyga: So you want access to a machine with a complete mirror on the file system?
[07:26] <zyga> shawarma: not access, just someone who will run a python extraction script
[07:26] <zyga> that script reads some basic info from each package and serializes it to a file
[07:26] <zyga> I can then process that file to generate data sets for cnf
[07:26] <shawarma> zyga: Ah, ok. Nothing that can be extracted from Packages and perhaps Contents?
[07:27] <zyga> shawarma: hmm?
[07:27] <Seveas> zyga, look at apt-file :)
[07:27] <zyga> shawarma: ah, unfortunatly no
[07:27] <Seveas> (if that's up-to-date for feisty)
[07:27] <zyga> apt-file doesn't know anything apart form the name
[07:27] <shawarma> zyga: I'm just curious about exactly what information you need that's not readily available.
[07:27] <zyga> shawarma: symlinks, hardlinks permissions and postinst script
[07:28] <zyga> apt-get source command-not-found
[07:28] <zyga> and check out UnifiedDataExtractor/scan.data
[07:28] <zyga> it's from the previous version but it's enough to understand what's going on
[07:28] <zyga> oh and architecture and repository
[07:29] <shawarma> zyga: I'm probably slow, but which part of that file cannot be extracted directly from http://archive.ubuntu.com/ubuntu/dists/feisty/Contents-i386.gz ?
[07:30] <zyga> shawarma: none, everything is there
[07:30] <shawarma> zyga: ..and the corresponding ones for other archs.
[07:30] <zyga> shawarma: hmm?
[07:30] <zyga> shawarma: I'd have to download each package
[07:30] <zyga> that's an option but it's usualy alot faster to just ask someone to run the script and be done with it ;]
[07:31] <shawarma> zyga: No, http://archive.ubuntu.com/ubuntu/dists/feisty/Contents-i386.gz contains a list of files in each and every package in the archive for i386.
[07:31] <zyga> hmm
[07:31] <zyga> w8
[07:31] <shawarma> zyga: You'd only have to fetch one for each arch.
[07:31] <zyga> I'll check it out
[07:31] <shawarma> zyga: Do that. :-)
[07:31] <zyga> I still need postinst contents
[07:31] <zyga> (for every damn package)
[07:31] <shawarma> zyga: For what?
[07:31] <zyga> I'm looking for update-alternatives
[07:32] <shawarma> zyga: To check for update-alternatives or stuff?
[07:32] <shawarma> zyga: Right,ok.
[07:32] <shawarma> gotta go
[07:32] <zyga> bye
[08:48] <tsmithe> who is in charge of planet ubuntu?
[08:49] <tsmithe> are they aware of http://ubuntu-linux.withishow.com/ ?
[08:49] <tsmithe> i don't feel comfortable with them taking the feed and spitting it out with adverts, and generating revenue on that
[08:50] <tsmithe> i didn't realise that by consenting to being aggregated by planet ubuntu, my work would be exploited elsewhere
[08:54] <mjg59> tsmithe: As the copyright holder of your content, you're free to send them a DMCA notification
[08:54] <tsmithe> DMCA?
[08:55] <tsmithe> i don't live in the USA, so i'm not sure what good that would do
[08:55] <mjg59> They're in the USA
[08:55] <mjg59> Therefore, they're subject to US laws
[08:55] <tsmithe> and that's all that matters?
[08:55] <tsmithe> good :)
[08:55] <mc44> yes
[08:57] <tsmithe> should i also notify the planet ubuntu operators?
[08:57] <mjg59> I don't see how that would help anything
[08:58] <andre_pl_> O-M-F-G. you people are amazing.  I thought Feisty was nice until I saw the WPA Support, and now I'm blown away... I have tried to get WPA working under edgy and gentoo for weeks and weeks to no avail.  wih festy is no harder than wep or unencrpyted networks.  Big HUGE Kudos.
[08:58] <tsmithe> well, canonical putting in a word might have greater effect than any word than me
[08:58] <tsmithe> even though that is an awful thing to admit
[08:59] <tsmithe> (why should a corporation have greater impact than an individual's voice?)
[08:59] <zyga> tsmithe: the fear of mighty lawyer army
[08:59] <mjg59> tsmithe: Canonical don't own the copyright
[08:59] <tsmithe> true. but they are providing the feed
[09:00] <mjg59> Yes. But they have no obvious legal standing here.
[09:00] <tsmithe> ok. so i'll just contact the owner of that site...
[09:01] <tsmithe> whoever that is
[09:01] <PriceChild> tsmithe, there's no details that I can find, and only dreamhost in the whois info
[09:01] <Mithrandir> send it to dreamhost, then.
[09:01] <tsmithe> sure thing
[09:01] <tsmithe> the hosting company have the power to bring it down
[09:02] <Mithrandir> or<EMAIL_ADDRESS>it seems
[09:02] <mc44> tsmithe: they even have a DMCA contact there<EMAIL_ADDRESS>[09:02] <tsmithe> juliux, what is this general admis list?
[09:03] <tsmithe> Mithrandir, so who is that?
[09:03] <juliux> tsmithe, i will search for it
[09:03] <tsmithe> i'll e-mail it to gwh@ and cc jeff@
[09:03] <Mithrandir> tsmithe: from http://withishow.com/about/
[09:03] <tsmithe> aha
[09:04] <PriceChild> gah how did I miss that :)
[09:04] <tsmithe> :)
[09:15] <hugo> BenC, hi
[09:16] <hugo> BenC, have anyone proposed the device manager suggested by you?
[09:17] <hugo> BenC, i am talking about the gsoc proposals.. =)
[09:35] <alex-weej> "    For computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon). It is not necessary for all (even most) processors made by AMD -- only their 64 bit chips."
[09:36] <alex-weej> that reads "[The AMD64 CD]  is necessary for their 64-bit chips."
[09:36] <alex-weej> this is wrong, no?
[09:36] <cjwatson> It => the CD
[09:37] <alex-weej> Yeah
[09:37] <cjwatson> oh, I see
[09:37] <alex-weej> http://releases.ubuntu.com/7.04/
[09:37] <mjg59> cjwatson: Any idea why migration-assistant appears to run depmod -a?
[09:37] <cjwatson> mjg59: fixed post-beta
[09:37] <mjg59> cjwatson: Rock
[09:37] <cjwatson> was just a mistake in os-prober
[09:37] <alex-weej> my friend installed the AMD64 version and i had to let him down that he has no flash player, skype, or win32 codecs
[09:37] <cjwatson> alex-weej: right, I guess the text is slightly off
[09:37] <alex-weej> cjwatson: should i launchpad it?
[09:38] <cjwatson> alex-weej: suggest better text to me and there's no need
[09:38] <mjg59> cjwatson: Also, I managed to break the partitioner - I deleted the existing partition that covered most of the disk, then hit new and set up a 10GB partition. Busy cursor appeared and nothing happened for 5 minutes, then I hit the cancel button and it quit
[09:38] <mjg59> parted_server was waiting for input from the fifo, not doing anything
[09:38] <cjwatson> mjg59: bug, /var/log/syslog + /var/log/partman
[09:39] <cjwatson> I'm not dealing with ubiquity bugs on IRC, I'd never get anything done. :)
[09:39] <mjg59> cjwatson: Are they archived anywhere post-install?
[09:39] <cjwatson> mjg59: /var/log/installer/
[09:39] <mjg59> Got them
[09:39] <mjg59> Will file later on
[09:39] <cjwatson> thanks
[09:39] <cjwatson> I know of 64-bit arithmetic breakage in the beta, but that's probably not what this is
[09:39] <mjg59> Oh - I restarted the installer and redid partitioning. Would that have blown it away?
[09:40] <cjwatson> no, it appends
[09:40] <mjg59> Cool.
[09:42] <cjwatson> alex-weej: how about I just replace the last sentence with "For non-64-bit processors made by AMD, use the i386 images instead."?
[09:43] <alex-weej> cjwatson: "Choose this if you have an AMD64 or EM64T based processor and wish to take full advantage of it. Note that you may still run the Intel x86 version on these processors. _Click here for more information_"
[09:43] <alex-weej> with a link to the wiki
[09:43] <alex-weej> because there are some advantages to running i386 on an amd64 (the 32-bit app support)
[09:43] <alex-weej> and you don't want to overwhelm the user at that stage
[09:43] <cjwatson> there are also considerable advantages to running amd64 on an amd64
[09:44] <mjr> s/may/can/ perchance
[09:44] <alex-weej> yes, but things like flash player / skype matter more to joe average :)
[09:44] <cjwatson> (funny how everyone thinks joe average == people they know)
[09:44] <mjr> I mean, it's not like it'd be forbidden to run it even if it wasn't possible ;]
[09:44] <alex-weej> i can't make assumptions for people i don't know, cjwatson :P
[09:44] <cjwatson> no, but if you don't know you don't get to make statistical claims
[09:45] <alex-weej> just change it so that it doesn't claim that it is "necessary" for amd64
[09:45] <alex-weej> but then amd64 users will still be confused when given the choice
[09:45] <cjwatson> that's tough, it's a valid choice which we can't simplify away
[09:45] <alex-weej> a wizard would be nice
[09:46] <alex-weej> Q. What's your processor? A. AMD64 | Q. Do you care about 32-bit application support? A. Yes | -> i386
[09:46] <cjwatson> I'm happy to add text, links, whatever, but not a wizard - there's enough complexity there already. Anything like a wizard belongs on www.ubuntu.com, not releases.ubuntu.com.
[09:46] <alex-weej> cjwatson: agreed
[09:46] <alex-weej> cjwatson: in that case, maybe even simplify it
[09:48] <alex-weej> oops.
[09:48] <cjwatson> Choose this to take full advantage of computers based on the AMD64 or EM64T
[09:48] <cjwatson> architecture (e.g., Athlon64, Opteron, EM64T Xeon). If you have a non-64-bit
[09:48] <cjwatson> processor made by AMD, or if you need compatibility with 32-bit
[09:48] <cjwatson> applications, use the Intel x86 images instead.
[09:48] <cjwatson> how about that?
[09:48] <alex-weej> sounds good to me
[09:48] <cjwatson> maybe s/compatibility with/support for/
[09:49] <alex-weej> yeah "support for"
[09:49] <cjwatson> actually, "full support for"
[09:49] <cjwatson> because the amd64 system *does* have some support for 32-bit applications - actually it's only really plugins that have a problem
[09:49] <alex-weej> btw, my friend tried to install the i386 skype deb and it whinged at him about the arch mismatch
[09:49] <cjwatson> or things with complex library dependencies
[09:49] <cjwatson> well, indeed
[09:49] <cjwatson> but that's not 32-bit applications, that's i386 .debs
[09:50] <alex-weej> because the deb package stuff still isn't quite multi-arch yet
[09:50] <cjwatson> I know.]
[09:50] <alex-weej> do you know what happened to that? i thought it was "close" about 2 years ago? :S
[09:50] <cjwatson> -> somebody else
[09:50] <alex-weej> shame
[09:50] <cjwatson> afaik just hasn't had time
[09:50] <alex-weej> oh well
[09:50] <alex-weej> but given that, it's /not/ just plugins that are the problem then is it?
[09:50] <alex-weej> at least atm
[09:51] <cjwatson> *shrug* "no support for 32-bit applications" is still inaccurate
[09:51] <alex-weej> but we're not saying it has no support there
[09:51] <alex-weej> we;re saying that for the best support, use i386
[09:51] <cjwatson> "if you need support for 32-bit applications, go here instead" implies that there is no support for 32-bit applications
[09:51] <cjwatson> "full support" is ok
[09:51] <alex-weej> well there's no support for i386 debs
[09:52] <cjwatson> yes but that's NOT THE SAME THING
[09:52] <alex-weej> i know
[09:52] <alex-weej> but to most people it would be :P
[09:52] <alex-weej> in a utopian world, where everybody ships debs :P
[09:52] <cjwatson> look, can we stop this? I said I'd say "full support" and that should be fine
[09:52] <cjwatson> you're kind of hammering on and on
[09:52] <alex-weej> i wasn't arguing otherwise...
[09:52] <alex-weej> sheesh
[09:53] <cjwatson> it's a Sunday night, tetchiness is to be expected :)
[09:53] <alex-weej> you were the one saying "compatibility with"? no, "support for"? no, "full support for"? no... :P
[09:54] <alex-weej> ctrl+W is easier in the heat of it all
[09:54] <alex-weej> (i didn't mean that :P)
[09:55] <cjwatson> I'll just say "if you need full support for 32-bit code" I guess and dodge the issue
[09:55] <cjwatson> ok?
[09:55] <alex-weej> fine by me
[09:55] <cjwatson> right, cool
[09:55] <alex-weej> but you could also just dodge it entirely and simply describe what the ISO is with no description of the implications
[09:56] <alex-weej> and leave it to a "wizard" on w.u.c
[09:56] <cjwatson> too late, committed, I'm going to do something more fun now ;)
[09:56] <alex-weej> ok :P
[09:56] <Mithrandir> alex-weej: dude, stop it now.
[09:57] <cjwatson> I appreciate the bug report and am grateful for it, but I don't really want to end up in an endless discussion of it ...
[09:57] <mjg59> Hm. Ok, so that didn't quite work.
[11:01] <hunger> Now that the vitualbox kernel module is in feisty, do you consider adding the rest as well?
[11:04] <superm1> BenC, ping
[11:11] <shawarma> hunger: /win 3
[11:11] <shawarma> whoops
[11:23] <hugo> BenC, are you there?
[11:23] <superm1> hugo, i pinged him about 20 min ago, wasnt here at that point
[11:25] <superm1> BenC, i've gotta run, but i just wanted to bring bug 69534 to your attention.  i finished up the patch and wanted to see if you could look it over and let me know what you think of it.
[11:25] <ubotu> Malone bug 69534 in linux-source-2.6.20 "Add lirc to linux-source build tree" [Undecided,In progress]  https://launchpad.net/bugs/69534
[11:25] <hugo> superm1, thanks
[11:25] <superm1> i'll stop in later
[11:28] <zyga> does anyone around have any *practical* experience with debugging memory leaks in python programs?
[11:29] <desrt> i guess you mean finding memory leaks in C code called from python?
[11:29] <zyga> no
[11:29] <desrt> python has memory management
[11:30] <zyga> I'm wondering what the heck in a rather small program keeps hogging memory
[11:30] <desrt> it doesn't leak.
[11:30] <zyga> I'm using several pythonic libraries, some from python some from ubuntu/debian
[11:30] <zyga> okay: s/python/python-script/g
[11:30] <desrt> right... python scripts don't leak memory... unless you're linking to some C that does
[11:30] <zyga> the fact is: it seems to leak
[11:31] <desrt> so start looking for things that aren't leaks but seem like leaks
[11:31] <zyga> it can sure 'leak' in a sense that something keeps holding memory when you didn't mean to
[11:31] <zyga> I do get the difference I just want to get this over with
[11:31] <zyga> I tried gc.debug but it's worthless IMHO
[11:32] <desrt> i guess yr looking for some tool to backtrace where memory allocations are made from (ala massif?)
[11:32] <zyga> I'd like to be able to see a snapshot of the memory allocation tree
[11:32] <zyga> s/tree/graph/
[11:32] <zyga> and check out what's there that was not supposed to be around so long
[11:32] <desrt> tall order :)
[11:33] <zyga> gc.get_objects() is somewhat tricky as it tells me just that
[11:33] <zyga> but I need a smart way to make use of it
[11:33] <desrt> finding the objects probably won't be too much help
[11:33] <zyga> it might
[11:33] <desrt> yr gonna want to know what code path allocated them
[11:33] <zyga> the program is dead-simple
[11:34] <desrt> i guess you suspect a library?
[11:34] <zyga> I will know the objects once I see them
[11:34] <desrt> gotcha.
[11:34] <zyga> bah
[11:34] <zyga> apt_inst is binary
[11:34] <desrt> you already know more about this than i do.  clearly :)
[11:34] <zyga> so is apt_pkg
[11:34] <zyga> I don't know how to debug them :/
[11:35] <zyga> I really suspect there is a leak - a simple program that streams stuff from one place to the other just keeps getting bigger
[11:35] <zyga> after scanning several gigs of data it's over 400MB
[11:35] <zyga> and it should _not_ grow


[00:26] <bodhi_zazen> doctormo: did you see the email re: meeting yesterday ?
[00:30] <doctormo> bodhi_zazen: Yes, good news, things got sorted out :-)
[00:30] <doctormo> bodhi_zazen: anything extra?
[00:30] <bodhi_zazen> no
[00:30] <bodhi_zazen> I wanted to ask you, are you interested in helping develop membership criteria ?
[00:31] <bodhi_zazen> Otherwise I will work on it and present a rough draft for revision
[00:33] <doctormo> Oh and I'm lit in the middle of sysadmin class :-D
[00:34] <doctormo> bodhi_zazen: I can help, what do you need? drafting?
[00:55] <bodhi_zazen> np, can talk later, I am also busy ATM
[00:56] <bodhi_zazen> ideas / suggestions re mebmership criteria and categories (general membership, teachers, admin, students, content contributors, etc).
[03:36] <doctormo_> The class went well
[03:36] <doctormo_> http://doctormo.wordpress.com/2009/07/15/ubuntu-system-admin-class-command-line-basics/ <- video will be up when production tools work
[18:56] <renihanc> can anyone help with a hd mounting problem ?


[02:58] <tomreyn> kc2bez: it still returns a blank page if you access with a googlebot user agent. this *can* be the result of malware preventing detection, but can also be an anti bad bot mechanism configured by the server admins or the software in use (wordpress, i think), limited to non Google IP address ranges.
[02:59] <tomreyn> if you have a google web developer account where lubuntu.me is setup in, it would be good to verify its spiders can still access the site.
[03:01] <kc2bez> Thanks for the information tomreyn I will make sure it gets passed along.
[03:01] <tomreyn> https://support.google.com/webmasters/answer/9012289?hl=en
[03:01] <tomreyn> i don't want to promote google services, but it's a de facto monopoly, so...
[09:05] <leokolb> kc2bez - Any idea why yesterdays ISO did not get updated on the testing tracker QA site?
[09:17] <RikMills> leokolb: the build failed at the publishing stage by the looks of it
[09:17] <RikMills> https://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/impish/daily-live-20210528.log
[10:44] <guiverc> thanks RikMills & leokolb
[13:01] <saivinob> Hi, is Quassel being updated to change its defaults (to Libera) like Konversation and Hexchat are?
[13:02] <saivinob> I am on 21.04 install and it still defaults to irc.ubuntu.com:8001
[13:16] <RikMills> saivinob: irc.ubuntu.com will change to point to libera.chat soon
[13:16] <RikMills> so I have read
[13:18] <saivinob> Noted. Including for TLS?
[13:20] <RikMills> yes, afaik
[13:21] <saivinob> Thanks.
[13:22] <saivinob> Do you or others know what package is 'application menu'?
[13:26] <saivinob> I mean of course you (team here) know. That was wrong question :-) I wanted to know what it is called.
[13:27] <saivinob> I only see `lxmenu-data` but not `lxmenu`.
[15:29] <kc2bez> `irc.ubuntu.com` has already been CNAME'd to `irc.libera.chat` so it should "just work".
[15:30] <kc2bez> I see saivinob left but the application menu isn't  a separate package it is part of the panel.


[00:12] <wxl> @tsimonq2: lxqt-qtplugin
[00:35] -lugito:#lubuntu-devel- [rMANUALee48cc09d57c: Add vlc pitch adjust] lynorian (Lyn Perrine) committed: https://phab.lubuntu.me/rMANUALee48cc09d57c
[00:48] <wxl> @lynorian: since you are the goddess of documentation, you interested in doing some work for upstream? there are a bunch of hidden features in pcmanfm-qt that could use documentation, as well as a general help guide. i'm sure you could use much of what you already have and this could also benefit our documentation, too. https://github.com/lxqt/pcmanfm-qt/issues/550
 I should eventually
[00:55] <wxl> cool well subscribe yourself to that bug
[01:05] <Joel8> When can I upgrade to 19.04 from 18.10 i386?
[01:32] <lynorian> wxl done
 Can someone point me to an easy program that needs packaging on Phab?
 I'd like to try one but with reference to just the first few Debian guides for packaging
 (Photo, 320x320) https://i.imgur.com/SrozsR9.jpg
[13:22] <tsimonq2> wxl: ^^^^^^^^^^^^^^^
[13:22] <tsimonq2> wxl: wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl wxl
[13:22] <tsimonq2> XD
 @SamuelBanya [I'd like to try one but with reference to just the first few Debian guides for p …], maybe sddm configuration tool?
 Ok I'll try looking for the related task on Phab
 @SamuelBanya https://phab.lubuntu.me/T20
 Sweet thanks
 I subscribed to it. Not sure how to assign it to myself
[13:28] <kc2bez> tsimonq2: You're the one!
[13:28] <kc2bez> I might not be able to make today's meeting. Apologies in advance.
 @SamuelBanya [I subscribed to it. Not sure how to assign it to myself], no need to at this moment.
 @SamuelBanya I forgot that sddm in in Cpp maybe not the best to start.
[13:55] <teward> *explodes the server*
[16:50] <wxl> good job @tsimonq2
 Ah gotcha
 Let me know if there's anything easier
 Sorry I haven't been active on the reddit.
 M
 It's all good :)
 My account was suspended for an unknown reason, and is just now being restored.
 Ouch :/ let us know when that's restored
 I just got back in now.
 Oh, sweet
 it was suspended because Simon.  *shot*
 I have no idea. I got an email letting my know it was suspended.
 Emailed support.
 Got no response.
 Then a few days later I got an email it was restored, and all was back to normal.
 @teward001 [it was suspended because Simon.  *shot*], hah
[18:33] <wxl> @tsimonq2: lxqt-qtplugin lxqt-qtplugin lxqt-qtplugin
 @wxl [<wxl> @tsimonq2: lxqt-qtplugin lxqt-qtplugin lxqt-qtplugin], Are you nervous, because the patch fails? Caused by https://github.com/lxqt/lxqt-qtplugin/commit/b1abe51484ad253a768f57594570bc3e3f16e362
[19:06] <wxl> @apt-ghetto nope. i mean i guess i could compile it and all but it should be fairly trivial to merge....
 Apropos lxqt-qtplugin, there is also this open PR => https://github.com/lxqt/lxqt-qtplugin/pull/48
[19:36] <wxl> yeah we'll probably want that ultimately
 @SamuelBanya [Let me know if there's anything easier], what should be easy is to port redshift-gtk to qt, and then package it.
 or kvantum
[20:06] <wxl> or cherry-pick some unreleased fix in some lxqt component
 We know that upstream LOVES that XD
[20:08] <wxl> nah, that's not what they hate as much as things that are uniquely ours
[20:08] <wxl> unfortunately their release schedule is.......
[20:08] <wxl> wait, what release schedule?
 XD
[20:09] <wxl> i'd say to do the same with calamares but they actually release on a regular basis
[20:09] <wxl> and often, too
[20:10] <wxl> if you want to be dangerous, grab the shift-to-scroll-by-one-item patch that isn't even merged yet
[20:10] <wxl> (in libfm-qt)
[21:06] <wxl> ok meeting time
[21:06] <wxl> who's here?
 I've been too busy conferencing it up
 Gave a few talks
 Was invited to the new release Trello
 Going to send an email about that Soon
 Hmmm
 Oh
 Poked Adam about a new util-linux since the new kpmcore will need it
[21:07] <wxl> that it?
 Fixed Lubot
 That's it
 Thanks
[21:08] <wxl> k
[21:08] <wxl> @tsimonq2: a reminder again about lxqt-qtplugin and note that there's an upstream change that appears to improve the one agaida cherry picked https://github.com/lxqt/lxqt-qtplugin/pull/48
 ok
[21:09] <wxl> so here's my barrage
[21:09] <wxl>  * BUG TRIAGE
[21:09] <wxl>    * After a long discussion and rabbit hole regarding varying definitions of the gigabyte, created and triaged a bug about failing to install when disk/RAM equals minimum requirements: bug 1826628
[21:09] <wxl>    * Commented on a recently expired bug about lxqt-config-monitor failing to load with VT autlogin + `xinit`; tl;dr coulnd't reproduce and out of scope anyways: bug 1817449
[21:09] <wxl>    * Asked for more info on a bug I don't even understand: bug 1826958
[21:09] <wxl>    * After mailing list discussion, didn't quite get the change to mouse scrolling behavior in pcmanfm-qt I wanted, but there is an alternative option waiting to be merged; downstream bug to track dupes: bug 1827097
[21:09] <wxl>  * TASKS
[21:09] <wxl>    * Expanded upon the bug about the minimum requirements: https://phab.lubuntu.me/T72
[21:09] <wxl>    * favicon needed on website: https://phab.lubuntu.me/T73
[21:09] <wxl>    * need more Lenny on website: https://phab.lubuntu.me/T74
[21:09] <wxl>    * need Lenny for Eoan: https://phab.lubuntu.me/T75
[21:09] <wxl>    * need new looks for Eoan: https://phab.lubuntu.me/T76
[21:09] <wxl>    * set Chris loose on testing battery status and closed it as invalid: https://phab.lubuntu.me/T71
[21:09] <wxl>  * TESTING
[21:09] <wxl>    * Tested the modifier-based override on mouse scrolling behavior in pcmanfm-qt: https://github.com/lxqt/libfm-qt/pull/419
[21:10] <wxl> looks like lubot is broke again
 Wat?
[21:11] <wxl> it should have done something with those task links
 You mean Lugito
 But yeah
 That
[21:13] <wxl> @lynorian @kc2bez @aptghetto @teward001 ?
[21:13] <wxl> OH @tsimonq2 were you going to SRU the fix in libfm-qt for the weird anti-file on the desktop?
 OH
 Yeah
[21:16] <kc2bez> Sorry tied up for a bit
[21:16] <wxl> k
 Hi, sorry but I don't have nothing new to tell beside some support in spanish channel
[21:20] <wxl> oh jeez i forgot all about @HMollerCl
[21:20] <wxl>  :(
[21:20] <wxl> still busy with the new job?
 yep
 Maybe wxl should look into making us an ubottu thing
 Just for this chan
 Something like !standup
 jajaja
[21:21] <wxl> oh that yells at all the team members
[21:21] <wxl> yeah i could do that
 Doeeet
[21:21] <wxl> i guess the question is who wants to be yelled at? :)
 OOH OOH ME ME ME
 all the onlines
 XD
[21:22] <wxl> ok well i guess i'll go for @tsimonq2 @lynorian @HMollerCl @aptghetto @teward001 @SamuelBanya and wxl[m]
[21:24] <wxl> aaaaaaaactually i'm going to make a general task for factoids
[21:25] <wxl> i could make an offtopic-#lubuntu that is specific to us that includes telegram
 Ooh
[21:28] <wxl> hm
[21:28] <wxl> !deb
[21:28] <wxl> !deb | wxl
[21:28] <wxl> interesting
[21:28] <wxl> !forum | wxl
[21:28] <wxl> ok i'm going to pick on you @tsimonq2 sorry
[21:29] <wxl> !deb | tsimonq2
[21:29] <wxl> !forum | tsimonq2
[21:29] <wxl> hm, i'm not sure why some have <reply> and some don't
[21:29] <wxl> well i'll figure this out elsewhere
 Hey guys checking in. I'll give that Phab task a shot though let me know if anyone is okay with annoying them about packaging
 I tried asking #ubuntu-devel about their iso tester but haven't got any bites no matter how many times I've tried on their irc
[21:33] <wxl> you can always ask here
[21:36] <wxl> !standup
[21:36] <wxl> aw hell
[21:38] <wxl> oh jeez
[21:38] <wxl> i forgot we have ubot93 here :/
[21:41] <wxl> that won't go live until later. i guess ubottu propogates to the other bots on a cron schedule
[21:46] <kc2bez> I'm here for a few then I have to drive for a while.
[21:47] <wxl> go
[21:47] <kc2bez> I packaged cala for stable CI
[21:48] <wxl> oooooooOOOOOOoooooooOOOoooooOOoooOOOooOOooooo
[21:48] <kc2bez> Tested an install on physical hardware
[21:48]  * wxl high 5s kc2bez
[21:48] <kc2bez> Luks on bios
[21:48] <kc2bez> Went as expected
[21:48] <kc2bez> Checkout the language selection
[21:49] <kc2bez> I think it is what you were looking for wxl
[21:49] <kc2bez> That is all I have to report for now.
[21:50] <wxl> that's great!
[21:50] <kc2bez> Thanks wxl.
[21:52] <kc2bez> I will be on the road for a bit. Feel free to ping me if you need anything.
[21:53] <wxl> thx kc2bez be well
[22:16] <wxl> !standup
[22:16] <wxl> darnit
[22:20] <Eickmeyer[m]> That's a standup factoid.
[22:20] <Eickmeyer[m]> :P
[22:21] <wxl> !standup
[22:21] <wxl> finally
[22:21] <wxl> everyone ignore that :)
[22:21] <Eickmeyer[m]> This has been a test.
[22:22] <Eickmeyer[m]> Had this been an actual standup, it would've been Thursday.
[22:22] <wxl> ummmmm
 Hi... I am using Lubuntu in my laptop... Thank Lubuntu...
[22:27] <wxl> glad you're enjoying it @muhammadfadlun feel free to help us make it even better :)
[22:36] <Eickmeyer[m]> Yeah, yeah, I lost track of my days. My brain says Wednesday.
[22:36] <Eickmeyer[m]> wxl: ^
[22:37] <Eickmeyer[m]> I clearly haven't had enough coffee today.
[22:37]  * genii starts up another pot, washes out everyone's Lubuntu mugs