[21:39] <barry> veebers: ping
[21:41] <veebers> hey barry o/ what's the haps?
[21:42] <barry> veebers: hey, how's it been?!  wanted to chat about autopilot :)
[21:42] <veebers> barry: heh can't complain. sure what do you have in mind?
[21:43] <barry> veebers: we talked about some ftbfs with py35, which i think is in the proccess of being fixed, right?  there were two mps for that (mine being one, but it's merge conflicting now).  what can we do to get a new autopilot uploaded to wily that fixes the py35 compat problem?
[21:44] <barry> https://bugs.launchpad.net/autopilot/+bug/1488175
[21:44] <veebers> barry: right yeah sorry about that, so I had a fix and a bug fix setup ready to be siloed then I had to deal with issues with failing tests on wily (autopilot-qt, autopilot-gtk, xpathselect)
[21:45] <barry> veebers: related to py35?
[21:45] <veebers> barry: The release candidate that is sitting there now that I thought would be a quick release turns out there is an issue with it (well, an issue with an interaction w/ mir)
[21:45] <veebers> barry: so my quick landing fix isn't so quick now
[21:46] <veebers> barry: aye, 2 fixse, one being flake8 the other something else unrelated
[21:46] <veebers> barry: My plan for today is to revert the change that blocks the landing, and just land the flake8 changes (so the tests pass and it no longer fails to build)
[21:47] <barry> veebers: that would rock, thanks.  autopilot is seed in ubuntu so a top priority for me to fix for the py35 transition
[21:49] <veebers> barry: ah right, sorry for the delay. I was on vacation for a week which didn't help things :-\
[21:49] <barry> veebers: yeah, didn't you get the memo?  no vacations! :)
[21:49] <barry> veebers: seriously thanks, and do ping me if you need anything
[21:49] <veebers> barry: will do, thanks :-)


[00:03] <james_w> I'm unable to build anything in a jaunty pbuilder as aptitude won't install due to libapt, is anyone else seeing this?
[00:03] <ScottK> Did wxpython get fixed?  2.8 was fubar yesterday.
[00:04] <ScottK> Working here.
[00:04] <ScottK> james_w: You can switch your pbuilder to use the classic pbuilbersatisfydepends that uses apt.  Maybe it's better.
[00:07] <geser> james_w: is that inside the pbuilder or in the host system?
[00:07] <james_w> inside pbuilder
[00:08] <geser> I've update my jaunty pbuilder today without problems
[00:09] <geser> and there was no apt or aptitude upload in the last few weeks
[00:12] <james_w> idiot!
[00:12] <james_w> I was trying to build with a mix of jaunty and experimental
[00:19] <goshawk> hi, about armel support, i can see that the jaunty alpha-5 has "ixp4xx" and "versatile" versions, where can i find infos about the differencies?
[00:28] <ScottK> goshawk: I think there is an #ubuntu-armel channel (or something like that)
[00:28] <goshawk> ScottK: yep it's #ubuntu-arm i'm already there now
[00:28] <goshawk> thx
[00:29] <ScottK> OK.  That's the best place to ask.
[00:29] <ScottK> Mostly it's Europeans, so it's kind of not the best time.
[00:33] <cyberix> I think this bug has a wrong status https://bugs.launchpad.net/ubuntu/+bug/248231
[00:33] <cyberix> The package is already in Jaunty repositories
[00:33] <cyberix> What should the correct status be?
[00:34] <cyberix> s/sh/w/
[00:39] <ScottK> If it's already in Jaunty it should be Fix Released.
[00:48] <cyberix> ScottK: Should I leave the assignment in place or set it to nobody?
[00:48] <ScottK> It doesn't much matter.  Just change the fix released
[00:50] <cyberix> done
[00:51] <cyberix> thanks for help
[01:01] <Laibsch> Hi
[01:02] <Laibsch> Looking for help in getting python-4suite-xml to actually compile against python 2.6
[01:02] <Laibsch> http://launchpadlibrarian.net/23448421/buildlog_ubuntu-jaunty-amd64.python-4suite_1.0.2-7ubuntu1_FAILEDTOBUILD.txt.gz
[01:02] <Laibsch> is the build failure
[01:05] <geser> have fun figuring out why the build didn't produce for 2.5 hours no output at all
[01:06] <Laibsch> yeah
[01:06] <Laibsch> I have no clue about that either
[01:06] <james_w> does it work on your machine?
[01:06] <james_w> or is this the memory eating one?
[01:06] <Laibsch> Compiling, you mean?
[01:06] <james_w> yeah
[01:07] <geser> james_w: that's the same spot where I aborted my pbuilder build as it took already 1 GB swap plus my 5 GB RAM
[01:08] <james_w> urgh
[01:08] <james_w> does a rebuild with python 2.5 still work?
[01:09] <geser> the python2.5 part works (see in the beginning of the log)
[01:10] <ajmitch> geser: that's a rather large amount of memory to use for a build
[01:12] <Laibsch> I'm sorry, my local machine would be underpowered I assume
[01:13] <Laibsch> not enough RAM and not enough CPU, I guess
[01:13] <geser> ajmitch: it might be less as my pbuilder uses a tmpfs, but usually I don't need any swap to build a package
[01:13] <ajmitch> I think any machine would be underpowered if it keeps on chomping through memory like that
[01:18] <Laibsch> What can we do?
[01:19] <Laibsch> Is there any channel like #debian-python for ubuntu?
[01:19]  * Laibsch is not aware of such a thing
[01:28] <ScottK> Laibsch: There is not.
[01:28] <ScottK> Laibsch: What I would do is look upstream for a new release or in their VCS for changes for 2.6 compatibility.
[02:11] <Laibsch> ScottK: Do you think that would go  in despite the freeze?
[02:11] <Laibsch> Jaunty has the latest Debian version IIRC
[02:11] <ScottK> Laibsch: A patch to fix it definitely.  A new version maybe.  Certainly if it's the only way to fix it.
[02:19] <Laibsch> I'm chatting with the devs
[02:19] <Laibsch> It looks really bad
[02:19] <Laibsch> python 2.6 is a known problem
[02:19] <Laibsch> Last release was more than 2 years ago
[02:19] <Laibsch> I'm not sure there is gonna be a solution from upstream
[02:21] <ScottK> Not good.
[02:21] <ScottK> But you're going about it the right way.
[02:24] <etank> evening everyone
[02:25] <etank> i am trying to go through the motu recipes and i am stuck on the watch file one
[02:25] <etank> everything worked find until the 'debuild -S -sa' step
[02:25] <etank> here is the output that i got http://dpaste.com/6618/
[02:26] <etank> what could i have missed?
[02:29] <Laibsch> etank: I don't think that is watch-file related
[02:29] <etank> i dont think it is either
[02:29] <etank> it is just where i got stuck going through the recipe
[02:30] <Laibsch> Does the previous version build?
[02:30] <etank> https://wiki.ubuntu.com/PackagingGuide/Recipes/DebianWatch  this is what im going through
[02:30] <Laibsch> with none of your changes?
[02:30] <etank> Laibsch: it seems to be running
[02:30]  * Laibsch wonders how come everyone seems to have a @ubuntu.com address these days
[02:30] <Laibsch> seems or is?
[02:31] <etank> ran but failed at the end because of gpg issues
[02:36]  * etank wonders if it is because the watch file isn't in the new dir
[03:02] <dtchen_> Laibsch: not everyone =)
[03:07] <Laibsch> dtchen_: ??
[03:08] <Laibsch> not everyone?  I don't see the connection to anything I wrote
[03:08] <Laibsch> What are you referring to?
[03:10] <dtchen_> Laibsch: 18:30  * Laibsch wonders how come everyone seems to have a @ubuntu.com address these days
[03:13] <Laibsch> dtchen_: man "seems" ;-)
[03:15]  * JontheEchidna uses @kubuntu.org, but has @ubuntu.com too :D
[03:23]  * Laibsch just opened bug 338079 on the dire state of python-4suite and python 2.6
[03:25]  * ScottK has both and uses neither
[03:31] <savvas> what happened with bug 335741 ? should I subscribe sponsors for my patch proposal or is it about to be decided?
[03:34]  * ScottK isn't about to decide anything.
[03:42] <savvas> ScottK: do you happen to know if I package a new version for mobile-broadband-provider-info from svn this weekend, is it possible to make it for jaunty? it's basically an xml file with service provider information
[03:42] <ScottK> It's in Main, so no idea.  I'd ask pitti during European work hours tomorrow.
[03:43] <savvas> ok, thanks :)
[04:15] <cody-somerville> Is there a member of the MOTU Council around?
[04:27] <nhandler> cody-somerville: Most are probably sleeping. Although nixternal should still be up.
[04:42] <Kamping_Kaiser> Is there a person/channel i can ask in regarding python-apt breakage?
[04:49] <nixternal> cody-somerville: what's up?
[04:53] <ScottK> Kamping_Kaiser: I'd ask mvo tomorrow.
[05:16] <Kamping_Kaiser> ScottK, thanks.
[05:17] <Kamping_Kaiser> as python-apt is a package in Ubuntu, does that mean there will be a bzr branch of it somewhere on LP?
[05:18] <ScottK> Since it's in Main, usually.
[05:18] <ScottK> If you apt-get source the package it'll tell you in debian/control
[05:18] <Kamping_Kaiser> ok, thanks. I'll go and have a look.
[05:24] <Kamping_Kaiser> heh. the XS-Vcs-Bzr: 404s. guess i'm waiting for mvo tomorrow ;)
[05:53] <Toadstool> hello everybody
[05:58] <fabrice_sp_> Hello Toadstool
[05:58] <Toadstool> hi fabrice_sp_
[08:56] <directhex> is there a template for an RM request bug?
[09:18] <slytherin> can anyone please tell me who maintains seeds for mobile-meta package?
[10:32] <huats> geser: are you around ?
[11:33] <AnAnt> Regarding debian bug #411851 , I tried the pm-utils hook script but it didn't work, does Ubuntu something else other than pm-utils for suspend/resume ?
[11:34] <geser> huats: yes
[11:37] <eMerzh> If someone want to review my package at http://revu.ubuntuwire.com/details.py?package=sqliteman ... thanks
[11:40] <huats> geser: give me 1h I am about to eat :)
[11:40] <directhex> eMerzh, VERY minor style point, missing comma in deps in debian/control
[11:40] <eMerzh> erf...ok:)
[11:41] <directhex> eMerzh, and i don't think including a README.source is usual unless you're altering an upstream tarball
[11:42] <directhex> eMerzh, otherwise, i like it. it's well-packaged IMHO.
[11:43] <eMerzh> ok...thanks
[11:43] <directhex> no, i can't advocate, i'm not a DD
[11:45] <directhex> ehm, MOTU
[11:45] <directhex> whoops
[11:46] <eMerzh> hehe....i 'll corret this and ask again  :)
[11:47] <AnAnt> where can I ask about suspend/resume & pm-utils ?
[11:59] <slytherin> directhex: eMerzh: reame.source is needed if you are using a patch system.
[11:59] <directhex> slytherin, srsly? is that in the policy someplace?
[12:01] <slytherin> directhex: https://wiki.ubuntu.com/README.sourceHowTo
[12:01] <slytherin> directhex: policy 3.8.0
[12:04] <directhex> slytherin, at least it's only a recommended, so i won't be shot
[12:07] <ScottK> It's required by 3.8.0.
[12:09] <c_korn> the build of scilab-5.1 fails. but it succeeds in a ppa. the error is about empty translation files. can someone help me what to do? http://launchpadlibrarian.net/23510243/buildlog_ubuntu-jaunty-lpia.scilab_5.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[12:12] <geser> c_korn: that's easy: remove the empty po file in the clean target: [ -s modules/scipad/locales/fr_FR/scipad.po ] || rm -f modules/scipad/locales/fr_FR/scipad.po
[12:12] <geser> and so on for the others
[12:18] <c_korn> geser: is "install/scilab::" the right target  to put that in?
[12:21] <geser> c_korn: that should work too, as long as the empty po files are removed before the deb gets build
[12:23] <slytherin> geser: if the files need to be removed before the deb gets built then install isn't the right target, is it?
[12:25] <geser> slytherin: the debs gets build in the binary* target which usually depend on the build and install targets
[12:25] <slytherin> Oh, I always thought it gets in install target. :-(
[12:26] <geser> the install target only runs "make install" (or any equivalent) so the files are copied to the place from where the deb gets build
[12:26] <c_korn> slytherin may be right, because there are other commands in the install target already and I do not see them executed in the build log. so they are executed after the error I think
[12:27] <c_korn> http://pastebin.com/d15e454e9
[12:28] <c_korn> this is the debian/rules file
[12:32] <geser> pkgstriptranslations is called almost at the end of the build, only a few calls follow it, so it must be an other reason why the install/scilab target isn't called
[12:35] <sistpoty|work> hi folks
[12:36] <directhex> hello sistpoty|work
[12:36] <sistpoty|work> hi directhex
[12:39] <geser> c_korn: install/scilab isn't run on lpia as scilab is arch:all
[12:39] <geser> if you look at the i386 build log you will find the calls from install/scilab there
[12:40] <c_korn> geser: ah, yes. I see
[12:40] <c_korn> so what is the right target?
[12:43] <geser> c_korn: I'd propose the clean target
[12:45] <c_korn> geser: hm, but won't that be in the diff.gz afterwards because clean is called when debuild -S -sa? maybe I should write patches to delete those files?
[12:50] <geser> c_korn: delete files don't appear in the .diff.gz
[12:51] <c_korn> hm, ok
[12:51] <eMerzh> thanks for the note slytherin ... i'll just correct the comma then...
[12:52] <eMerzh> slytherin, or directhex  in fact... where must i put the comma? :s
[12:52] <directhex> eMerzh, you were missing a space, you have foo,bar somewhere
[12:53] <eMerzh> directhex, ok ... sorry :D
[12:54] <c_korn> geser: I will reupload scilab to revu. some has to upload it to jaunty again
[12:56] <geser> c_korn: open a sponsoring bug with the debdiff between jaunty and the new version
[13:00] <c_korn> geser: can I attach the debdiff in bug 272264 and reopen it?
[13:02] <geser> sure, that works too (but don't forget to close it again in your changelog entry)
[13:03] <c_korn> geser: like that? "  * debian/rules: Remove empty translation files (Closes LP: #272264)"
[13:06] <geser> c_korn: yes
[13:10] <DktrKranz> c_korn: commented for scilab
[13:11] <c_korn> DktrKranz: thanks. I used sbuild for testing in clean chroot
[13:12] <DktrKranz> having that package inside a chroot helps to triage those kinds of FTBFS
[13:12] <DktrKranz> (or to avoid them as well)
[13:15] <huats> geser: I am back
[13:16] <geser> huats: and I'm still here :)
[13:17] <huats> geser: great
[13:17] <huats> geser: so I am finally taking care of python-webkit....
[13:17] <huats> sorry for the delay
[13:17] <huats> for the python2.6 migration
[13:17] <geser> huats: no problem, it's not like python-webkit is the last package to transition
[13:17] <huats> is it ?
[13:18] <huats> do you have some link for this transition ?
[13:18] <huats> so that I can have a look at what needs to be done...
[13:18] <huats> or is it a simple rebuild stuff ?
[13:19] <geser> huats: https://lists.ubuntu.com/archives/ubuntu-devel/2009-February/027528.html
[13:19] <huats> geser: ok
[13:19] <huats> I am having a look
[13:19] <huats> and I let you know
[13:20] <geser> huats: over 200 (binary) packages still have a dependency on python < 2.6
[13:20] <huats> ok
[13:20] <huats> i though you were ironic :)
[13:21] <DktrKranz> huats: the best way I approach at them is using edos-debcheck, so you could have a look at it for targeted packages
[13:21] <huats> ok
[13:21] <DktrKranz> don't remember the exact command, but man pages is cool
[13:22] <huats> ok
[13:25] <directhex> DktrKranz, did you see my awesome collection of sync bugs for mono 2.0 lib transitioning? mostly done, already! :o (!)
[13:29] <DktrKranz> directhex: not yet, I've been mostly offline this week, but I noticed uploads in Debian. Thanks :)
[13:29] <Laney> RAWR
[13:29] <Laney> super efficient transitioners r us
[13:29] <directhex> good arvo, Laney!
[13:29] <Laney> yo
[13:29] <Laney> I upgraded my work pc to Jaunty and am now xless
[13:30] <directhex> Laney, this is my fear about upgrading my new home pc :|
[13:30] <directhex> Laney, i hope i can get sound out of intrepid
[13:30] <DktrKranz> Laney: it's not ubuntu fault, it's because of global warming
[13:30] <Laney> yeah, but if it's new then you have nothing to lose (except time)
[13:30] <Laney> DktrKranz: You mean I've gone back in time to before we had a problem?
[13:30]  * Laney is so 1970s about now
[13:31] <DktrKranz> Laney: you have the best GUI available, a TTY
[13:31] <c_korn> geser: I attached the debdiff and set the bug status to incomplete: https://bugs.launchpad.net/ubuntu/jaunty/+source/scilab/+bug/272264/comments/43
[13:31] <DktrKranz> :)
[13:31] <Laney> getdeb?!?!
[13:31] <directhex> is there a way to check the parameters on a module?
[13:32] <DktrKranz> c_korn: you have to use another revision for that
[13:32] <c_korn> oh, so it is 0ubuntu2 ?
[13:34] <DktrKranz> yes
[13:34] <DktrKranz> you can't reuse an already uploaded revision
[13:34] <DktrKranz> you can, if you like REJECT mails :)
[13:35] <directhex> i don't like those :<
[13:35] <savvas> decompyle package is removed
[13:35] <savvas> ..and awaiting the response for bmpx (bug 337659)
[13:35] <DktrKranz> directhex: especially Debian side ;)
[13:36] <directhex> DktrKranz, 2 months i've been waiting on moon i NEW. 2 months!!!
[13:36] <DktrKranz> directhex: is NEW shrinking now?
[13:37]  * DktrKranz has two packages in
[13:37] <directhex>  Package count in NEW: 361 |  Total Package count: 410
[13:37] <DktrKranz> gah!
[13:38] <directhex> indeed
[13:38] <DktrKranz> for package in NEW:
[13:38] <DktrKranz>     reject(package)
[13:38] <directhex> DktrKranz, i think it's spinlocking or something ;)
[13:39] <DktrKranz> heh
[13:39] <DktrKranz> I hope to see 3.0 packages support soon
[13:43] <c_korn> DktrKranz: is this debdiff fine? https://bugs.launchpad.net/ubuntu/jaunty/+source/scilab/+bug/272264/comments/44
[13:44] <ScottK> directhex: I had one come out of New recently, so there is some motion.
[13:44] <directhex> ScottK, binary new or source new? (even though the ftpmaster page doesn't distinguish)
[13:45] <ScottK> directhex: Source and they do distinguish.  Binary usually gets done more quickly.
[13:45] <DktrKranz> c_korn: not yet. You should use dch -i to add a new changelog entry, instead of mangling current one
[13:45] <c_korn> argh, I will get into it :P
[13:46] <directhex> ScottK, they distinguish in reality, but the ftp-master wobsite shows them both in the same queue, which is false
[13:49] <DktrKranz> directhex: ftp-master's NEW page is confusing, it lists binary NEW pkgs too, and it's really hard to say which are source NEW. I hope they have a better approach.
[13:49] <directhex> DktrKranz, someone did some hacking on that page recently. was it NCommander?
[13:50] <broonie> They're all equally NEW, the distinction is moer in teh internal sorting that DAK does.
[13:51] <ScottK> directhex: 'false' is really far too strong a word.
[13:51]  * broonie nods ScottK
[13:54] <directhex> perhaps it'd be clearer to me what was happening if i read debian-devel
[13:54] <directhex> but i try to avoid places that j00rg schilling might be
[13:54] <DktrKranz> :)
[13:54] <DktrKranz> directhex: once he mailed me
[13:54] <cody-somerville> ScottK, can you ack bug #193818 ?
[13:54] <broonie> directhex: There's one NEW queue. ftp-master process it in an order of their choosing (eg, doing quick things if they have little time).
[13:55] <directhex> DktrKranz, oh, me too. i had the audacity to file a bug on cdda2wav
[13:55] <broonie> directhex: the software provides a default sort for the queue when they go look at it which brings binary NEW stuff to the front.
[13:55] <broonie> (ftpmaster here being the humans that fulfil that role rather than the machine)
[13:56] <DktrKranz> directhex: mine was worse, he mailed me without previous contact by my side
[13:57] <DktrKranz> he saw I uploaded a revision of a similar package, and asked me some stuff about cdrtools
[13:57] <ScottK> cody-somerville: My first question would be why did slangasek decline it for Jaunty?
[13:57] <cody-somerville> ScottK, I imagine because someone nominated before FF or something.
[13:58] <cody-somerville> ScottK, However, in comment #16, he asks me if I could look at it this release
[13:58] <c_korn> DktrKranz: is this finally well done? http://pastebin.com/d7106162b
[13:58] <ScottK> cody-somerville: How tested is your new package?
[13:58] <ScottK> Yes.
[13:58] <cody-somerville> ScottK, I'm just building it now
[13:59] <cody-somerville> ScottK, However, 0.4 is rather obsolete.
[13:59] <DktrKranz> c_korn: much better now (at least for syntax).
[13:59] <NCommander> directhex, broonie, no, dak only had source NEWs, no binary NEWs like Ubuntu
[13:59] <NCommander> the binaries you are seeing are the binaries uploaded with the source package
[14:00] <c_korn> DktrKranz: should it be a for loop?
[14:00] <ScottK> cody-somerville: OK.  Tell me after you've tested it works (not just build) and sign up to be bug contact and I'll ack it.
[14:00] <directhex> broonie, i don't doubt that ftpmaster is a thankless, tedious, never-ending job, but it would be nice to get a better handle on why things can end up taking aeons. 2 months is a very long time, and the number of packages in NEW right now is mad. presumably there is post-release "stuff" to be done?
[14:01] <StevenK> NCommander: Actually, binary NEW is handled at the same time as source NEW
[14:01] <broonie> Some of it is folks taking a break after release.
[14:01] <broonie> NCommander: Not the case, *all* new binaries are NEW.
[14:02] <broonie> directhex: Some of it will be stuff being deliberately held up for transitions too.
[14:02] <directhex> broonie, ftpmaster goes on holiday just as everyone else is saying "lenny is out? quick, break the archive!" :D
[14:02] <DktrKranz> c_korn: not necessarily
[14:02] <NCommander> StevenK, dak uses the override for the source package, it doesn't have the concept of binary NEW unless I'm very much mistaken.
[14:02] <cody-somerville> ScottK, k
[14:02] <StevenK> NCommander: You're mistaken
[14:02] <broonie> NCommander: You're mistaken.
[14:02]  * StevenK high fives broonie
[14:02] <ScottK> Is there an echo in here?
[14:03] <broonie> (IIRC the actual implementation is that everything *must* have an override so things without an override are NEW).
[14:03] <c_korn> DktrKranz: well, a simple "find . -name '*.po' -empty -delete" would be better?
[14:03] <DktrKranz> directhex: but people prepare NEW and keep them under the pillow to push it right after release, just to "break stuff" (tm)
[14:03] <NCommander> So I upload a package through dak, the source package and the initial binaries go through, the binaries for other architectures don't get stuck in a NEW queue like on Ubuntu
[14:03] <broonie> directhex: In general there's never been any guarantee on new processing and it does get backed up from time to time.
[14:04] <DktrKranz> c_korn: I guess they're equivalent
[14:04] <broonie> directhex: If it's particularly urgent then pinging *may* help, providing it doesn't annoy anyone :)
[14:04] <DktrKranz> just do not delete good translations, the other point is just cosmetic
[14:04] <directhex> broonie, i'm not looking for an SLA, just a general "waa, i'm right near the top but it's been *ages*"
[14:04] <directhex> broonie, absolutely people are entitled to time off
[14:05] <james_w> NCommander: but if you add a -dbg package in the next upload that will hit NEW
[14:05] <broonie> NCommander: Yes, the override is arch all
[14:05] <directhex> DktrKranz, well, yes, you don't want to upload things to unstable whilst testing is frozen
[14:05] <DktrKranz> in Italy we say: "patience is for the strong ones"
[14:05] <broonie> directhex: The queue has never been officially sorted, often the easy stuff is cherry-picked out first.
[14:05] <NCommander> james_w, oh ... sorry, when I think of binNEW, I think of Ubuntu's binNEW, as a per archietecture override.
[14:05] <NCommander> james_w, your right thats how dak works, but I wasn't thinking about it in the same terms.
[14:06] <directhex> DktrKranz, in the uk, we say "move yer arse!"
[14:06] <c_korn> DktrKranz: ok, thanks. https://bugs.launchpad.net/ubuntu/jaunty/+source/scilab/+bug/272264/comments/45 now I should wait for mok0?
[14:06] <directhex> ;)
[14:06] <DktrKranz> directhex: heh. we like sleeping :)
[14:17] <DktrKranz> c_korn: I haven't a build server handy, I'll probably review it this evening
[14:17] <DktrKranz> but thanks for the debdiff :)
[14:17] <c_korn> well the 0ubuntu1 made it to the install target. and this change should fix the translation error.
[14:30] <c_korn> DktrKranz: so are you assigned to scilab now? or should I tell mok0 when he comes online?
[14:34] <DktrKranz> c_korn: I can do it as well, but if mok0 (or someone else) grabs it first, I can't argue
[14:35] <c_korn> ok
[14:35] <DktrKranz> my main interest is to process FFe quicker once approved
[14:36] <c_korn> yeah, I know. FF is far over. now there needs some other work to be done
[14:37] <DktrKranz> or catching up regressions in time
[15:02] <RainCT> uhm.. indicator-applet isn't working here
[15:06] <RainCT> wow, I've found an emoticon representing jono -> http://flames.aptivastudio.com/images/smilies/icon_e_ugeek.gif  *g*
[15:07] <james_w> heh
[15:08] <bddebian> Heya gang
[15:09] <directhex> hello bddebian
[15:09] <bddebian> Hi directhex
[15:52] <pochu> any native speaker? what is correct, "a speficied port" or "an specified port"
[15:52] <pochu> I could also use "a given port" :)
[15:55] <directhex> a
[15:55] <directhex> technically, you use "an" to add a consonant between a and a word starting with a vowel
[15:55] <directhex> so "an apple" instead of "a apple"
[16:04] <Zarel> Vowel sound, to be exact.
[16:04] <Zarel> Hence little exceptions like "an hour"
[16:05] <directhex> oh, yes
[16:05] <directhex> whoopsie
[16:07] <ScottK> jpds: There was a bug against MoM with a patch for grab-merge.sh to use https.  Please make sure the version you are putting into ubuntu-dev-tools has that fix.
[16:14] <Toadstool> now I feel stupid, I was so convinced the next motu council meeting is tomorrow :p
[16:15] <Laney> when was it?
[16:15] <Aquina> today?
[16:15] <Toadstool> next week :)
[16:15] <Laney> heh
[16:15] <Aquina> So what about the marble packet? :D
[16:15] <Aquina> oh..
[16:24] <ScottK> jpds: Of course now I can't find the bug.  It was just changing http/https throughout.
[16:30] <ScottK> jpds: So I checked and it's the right one.  Nevermind.
[17:32] <vadi2> What is the proper way to supercede a package? (for example, the program was renamed)
[17:34] <slangasek> ScottK: because there are no controls on who nominates what for release, and all kinds of bugs show up on the nomination list that there's no reason we should track release-wise
[17:35] <ScottK> slangasek: OK.  Sounds reasonable.  Just wanted to make sure it wasn't something more specific.  Thanks.
[17:36] <maix> hi, is there a way to say "this packages requires package xy in a version between 1.0 and 2.0"?
[17:36] <maix> i cannot find docs about the requires header anywhere
[17:37] <ScottK> Use two separate depends.  One for the less than and one for the greater than.
[17:38] <goshawk> RainCT: hi
[17:39] <ScottK> maix: python (<< 2.7), python (>= 2.6), is a real live example from a package.
[17:39] <vadi2> how can I make it so package B supercedes package A, but when package A is removed, it doesn't want to remove package B?
[17:39] <maix> ok thanks
[17:39] <maix> what's the difference between << and < ?
[17:39] <maix> i know that from maths, but what does that mean with packages?
[17:40] <jpds> ScottK: OK (I thought they fixed the mod_ssl stuff).
[17:41] <jdong> maix: < > are not accepted
[17:41] <maix> oh *g*
[17:42] <jdong> see man deb-control for more info
[17:43] <maix> ah that's helpful, thanks
[17:43] <maix> another question: why is 1.0 and 1 not the same version?
[17:44] <ScottK> maix: Because they aren't the same.
[17:45] <maix> well ;)
[17:45] <jdong> maix: man deb-version? :)
[17:46] <jdong> (see under Sorting Algorithm)
[17:46] <jdong> the short answer is that it makes the sorting algorithm a simple concise no-surprises lexicographical comparison like traditional string-comparison operators.
[17:47] <maix> hm
[17:47] <maix> is there some convention to never use trailing .0s or something like that?
[17:48] <jdong> you mean in the debian/ubuntu part of the version string?
[17:50] <maix> no, anywhere
[17:50] <maix> or how shall i compare that else?
[17:51] <jdong> well we have no control (no pun intended) over how upstream projects version their projects.
[17:51] <maix> shall i write << 2.0 or << 2 or << 2.0.0 ?
[17:51] <jdong> that depends on how upstream versions their projects.
[17:51] <maix> of course, but one could change it
[17:51] <jdong> but for all intents and purposes they'd probably all do the same thing.
[17:52] <jdong> depending on how specifically upstream versions their product :)
[17:52] <Zarel_> https://launchpad.net/ubuntu/+source/warzone2100
[17:53] <maix> ah i'll just use 1.0, thats greater than 1 anyways so there'll be no problem
[17:53] <Zarel_> What does "current" mean in this context? -> intrepid  	current
[17:53] <maix> thank you two though
[17:54] <jdong> Zarel_: the latest released version of Ubuntu.
[17:54] <jdong> the field refers to the status of the Ubuntu release to the left.
[17:54] <Zarel_> jdong: So if it's "current", that means it should get bugfix updates, right?
[17:55] <jdong> Zarel_: in accordance to the StableReleaseUpdates policy.
[17:55] <jdong> !sru
[17:55] <jdong> that also applies to supported.
[18:01] <Zarel_> So only major bugs get fixed? :(
[18:20] <eMerzh> i'm looking for an advocate by a motu for my package http://revu.ubuntuwire.com/details.py?package=sqliteman .... thanks :)
[18:20] <ScottK> !backports | Zarel
[18:27] <Laney> huats: are you OK with python-webkitgtk? Noticed you said you were unwell earlier
[18:29] <Laney> jcfp: And you with sabnzbd?
[18:29] <Laney> chasing up a few uninstallable apps
[18:30] <jcfp> Laney: it's in the works, python-support giving me trouble although I seem to have found a way around that now
[18:30] <Laney> excellent
[18:30] <Laney> let me know and I'll sponsor it right away
[18:31] <Laney> oh, wait, it needed an FFe
[18:31] <Laney> let me know after you have that ;)
[18:44] <jcfp> Laney: if I patch the app to use /usr/bin/python2.5 in the shebang line, set debian/pyversions to 2.5 only and build in jaunty, ${Python:Depends} expands to include a hard depend on python (<< 2.6) which is uninstallable.
[18:44] <Laney> guh
[18:44] <jcfp> If I leave pyversions empty, it works fine; anything that includes 2.6 (like "2.5,2.6" or "2.5-") also works although the automatic deps on python don't make too much sense to me.
[18:45] <Laney> I'm really not very expert at python packaging
[18:45] <Laney> you might ask #debian-python or whatever their channel is
[18:45] <Laney> or wait for someone who knows more
[18:45] <huats> Laney: I am fine thanks
[18:46] <Laney> ah, good
[18:46] <huats> I am about to publish it
[18:46] <huats> thaks Laney
[18:46] <Laney> \o/
[18:47] <jcfp> I might just try asking on debian-python too, altough they haven't moved to python 2.6 yet
[18:48] <slytherin> need a bit help with gcc. I have a file which uses rand function (defined in stdlib.h). Even if the stdlib.h file is included I get error with gcc, undefined reference.
[18:55] <maxb> slytherin: could you pastebin buildlog?
[18:56] <slytherin> maxb: found the problem. wrong return type. :-(
[19:03] <Laney> Anyone able to help with some python/boost fun? Miro fails to build (and I'm told it is incompatible with 2.6 anyway) with errors relating to boost-python. http://orangesquash.org.uk/~laney/miro_ftbfs.txt
[19:29] <slytherin> StevenK: please let me know if I should file a bug for this. ubuntu-network-remix has dependency on cupsys-driver-gutenprint which is transition package. Also it has dependency on ubuntu-artwork which is redundant IMHO since there is also dependency on human-netbook-theme
[19:29] <fabrice_sp> Hi huats. anjuta is FTBFS. As I think I'm able to fix it, do you let me touch the package?
[19:30] <khashayar> Pencil (http://revu.ubuntuwire.com/details.py?upid=5149) is in good shape now and needs a couple of advocates. Is anyone up for it? (FYI, we're filing a FF exception for it). Thanks.
[19:31] <geser> fabrice_sp: create a patch and get it sponsored
[19:33] <fabrice_sp> geser, that's just the huats uploaded it few days ago, so I was wondering if he was working on it
[19:42] <jelmer> Is there some way to mark a bugreport relevant only to intrepid?
[19:43] <jelmer> I can see how to report a *new* bug for just intrepid, but moving an existing one seems to be harder
[19:43] <ScottK> jelmer: Yes.  Nominate for release and then mark it fixed/invalid/etc overall
[19:43] <ScottK> jelmer: I didn't hear back from you so I'm updating samba4.
[19:43] <jelmer> ScottK: Sorry
[19:44] <jelmer> ScottK: Ok
[19:45] <ScottK> jelmer: For future reference (when Debian gets 2.6) the changes are build-dep python2.5-dev -> python-dev and site-packages/*-packages in rules and the .install for the two python packages.
[19:46] <jelmer> ScottK, cool, thanks
[19:48] <huats> fabrice_sp: I have uploaded a new version today
[19:48] <huats> to fix that
[19:49] <fabrice_sp> ok. I'll look for others FTBFS :-)
[19:49] <fabrice_sp> thanks huats
[19:49] <huats> no problem fab
[19:49] <huats> no problem fabrice_sp
[19:49] <huats> and thanks :)
[19:50] <fabrice_sp> you can call me Fab ;-)
[19:50] <huats> fabrice_sp: it is easier with the completion :)
[19:51] <fabrice_sp> lol yes
[19:51] <Andre_Gondim> I'm trying to pack one program, but I don't if this debian/control file is correct http://paste.ubuntu.com/126894/
[19:59] <miik> why you dont put LimeWire in repo??
[20:00] <hyperair> miik: LimeWire isn't free.
[20:02] <miik> but its GPL
[20:02] <miik> wikipedia says so
[20:02] <miik> http://en.wikipedia.org/wiki/LimeWire -- License 	GNU General Public License
[20:05] <hyperair> hmm seriously?
[20:05] <hyperair> interesting
[20:05] <hyperair> well why don't you package it then? =)
[20:05] <huats> fabrice_sp: as you can see https://edge.launchpad.net/ubuntu/jaunty/+source/anjuta/2:2.25.902-0ubuntu2 anjuta builds now :)
[20:05] <hyperair> either way i think limewire's crippleware. limewire pro is where all the features are
[20:05] <jdong> heh it's not exactly without its marred history in the past.
[20:06] <jdong> I guess the correct answer to the question now is "because nobody has cared enough to put the time into packaging it"
[20:06] <hyperair> miik: i'd concentrate on frostwire.
[20:06] <miik> hyperair, icant find that in repo either
[20:06] <hyperair> but that has some issues with licensing or whatever
[20:06] <hyperair> miik: yeah because there were licensing issues or something
[20:06] <hyperair> even if it says it's GPL
[20:07] <hyperair> https://bugs.launchpad.net/ubuntu/+bug/94011
[20:07]  * slytherin loves transmission
[20:07] <miik> oh
[20:07] <jdong> indeed.
[20:07] <jdong> not MUCH different from the azureus debacles in the past.
[20:08] <jdong> i.e. the main thing is FOSS but they bundle a couple native precompiled libs
[20:08] <miik> but smeone put frostwire request 2 years ago
[20:08] <miik> they dont put it in repo
[20:08] <jdong> and figuring out what the heck they are is more of a challenge than expected.
[20:08] <jdong> does the upsteram source STILL bundle precompiled libraries?
[20:08] <ScottK> miik: There are a lot more requests than people willing to do the work.
[20:09] <miik> :(
[20:09] <miik> well, what does all the guys mark pays does?
[20:09] <rgreening> ScottK: I started on it.. but ran into packaging issues :)
[20:09] <ScottK> .jar is a binary, right?
[20:09]  * ScottK knows about zip about Java
[20:09] <jdong> ScottK: in most cases yes
[20:09] <jdong> ScottK: it's a ... no pun intended.. zip file.
[20:09] <miik> i wish redhat, gentoo, ubuntu, suse all shared repository
[20:09] <jdong> in it can be source or .class binaries
[20:09] <ScottK> limewire is chock full of them.
[20:09] <slytherin> ScottK: you can say that
[20:10] <jdong> a "runnable tarball" if that sounds any better :D
[20:11] <slytherin> does anyone know how to debug issues with cdrom device access?
[20:11] <ScottK> miik: It'd take a person who was reasonably expert in Java, Debian packaging, and licensing to go through their tarball as see if it was actually legal to go in the repositories.
[20:12] <miik> its GPL, i would assume it is...
[20:12] <ScottK> miik: One common problem we hit with Java packages is they are licensed GPL so was can't distribute without the source, but then they don't provide the source.
[20:12] <miik> oh
[20:12] <jdong> miik: a lot of things say they are GPL are not truly GPL compliant :)
[20:12] <ScottK> So without that, we can't have it in the repo at all.
[20:12] <miik> oh
[20:12] <miik> but if i want use limewire on windows, i can just do that...
[20:13] <miik> but on ubuntu, i cant =/
[20:13] <ScottK> Dunno if that's the case here at all.
[20:13] <jdong> well if it is truly Java it shouldn't be hard to run from jar.
[20:13] <ScottK> Limeware could make .debs and distribute them.  We can't.
[20:13] <rgreening> Limewire has debs iirc
[20:13] <rgreening> and so does frostwire
[20:14] <slytherin> does limewire or frostwire use bittorrent protocol?
[20:15] <jdong> slytherin: partly
[20:15] <jdong> they support it but AFAIK theyare primarily gnutella-ish clients
[20:17] <RainCT> thekorn: nice screencast :)
[20:18] <slytherin> packaging big java application from scratch can be frustrating experience at times. I experienced it first hand with jmeter.
[20:20] <thekorn> RainCT, thanks, I plan to push leonov a bit more over the next few weeks
[20:20] <miik> well aslong as you cant run open source software on linux, it seems windows is a better platform for running open source software
[20:20] <miik> open source software is better supported on windows than on linux
[20:20] <miik> i can run limewire on windows, but not on linux
[20:21] <miik> so people should migrate from linux to windows in order to better use open source software to save costs and get a lower tco
[20:25] <miik> i can use cross-platform applications such as limewire on windows
[20:25] <slytherin> miik: one application != open source software.
[20:25] <miik> but i cannot use cross-platform applications on linux
[20:26] <miik> there are thousand applications
[20:26] <miik> just needs-packaging on bugs.ubuntu.com
[20:26] <slytherin> miik: and I fail to understand why you can't run limewire as distributed by their website on linux
[20:28] <fabrice_sp> huats, great! :-) You just added a build dependency, right? Oh: I can see it in the changelog :-) By the way, it still appears as FTBFS in ubuntuwire
[20:29] <slytherin> RainCT: which screencast are you talking about?
[20:30] <slytherin> fabrice_sp: ftbfs page usually takes a day for update.
[20:30] <fabrice_sp> ok
[20:32] <fabrice_sp> by the way, I have a sync request that has been acked to authorize the FFE. Do I nned to subscribe MOTU or directly the Arhcive admin?
[20:33] <fabrice_sp> it's bug #336904
[20:33] <Laney> do you need sponsorship?
[20:33] <slytherin> fabrice_sp: i believe motu since someone will need to add an ack that it builds fine.
[20:34] <thekorn> slytherin, I *think* he talked about http://launchpadlibrarian.net/23523147/leonov_multible_content_MainContent.ogv
[20:34] <fabrice_sp> Laney, I just applied yesterday to U-C-D, so no upload rights for the moment :-)
[20:34] <Laney> then you need sponsorship
[20:34] <Laney> u-u-s it is!
[20:35] <fabrice_sp> ok. As motu-release members are motus, I had a doubt. Thanks!
[20:35] <fabrice_sp> thanks Laney and slytherin
[20:38]  * slytherin calls it a day
[20:39] <Laney> oh dear
[20:39] <RainCT> thekorn: Great. I'd get back to do some work, but I'm already overloaded with other stuff and school :(
[20:39] <Laney> muting my audio makes a horrible sound come out of the speakers
[20:51] <huats> fabrice_sp: I guess there is a cache.. that is why it is still FTBFS
[20:55] <Laney> anyone got a sync ack script?
[20:56] <ajmitch> why would you use a script for such a thing? :)
[20:57] <Laney> because otherwise acking is several clicks
[20:57] <ajmitch> though you'd at least be looking at the LP bug anyway
[20:58] <ScottK> Laney: I'd suggest filing bugs against LP asking for the workflow to be streamlined.
[20:58] <Laney> ScottK: Isn't syncing support coming to LP anyway?
[20:59] <ScottK> Laney: I've heard so.
[20:59] <Laney> me too
[20:59] <ScottK> No idea if it's actually going to happen.
[20:59]  * Laney asks
[21:09] <joaopinto> what is the max allowed length for a package name ?
[21:17] <RainCT> joaopinto: how long is your name?
[21:18] <joaopinto> RainCT, that does not answer my question, I am defining a table and I need a max value for the package name field
[21:18] <joaopinto> that is not
[21:20] <RainCT> joaopinto: Debian Policy doesn't say anything about the length (file:///usr/share/doc/debian-policy/policy.html/ch-controlfields.html#s-f-Package)
[21:20] <joaopinto> RainCT, I have read the policy :P
[21:21] <maxb> I don't think there is a maximum length. In practice it's a matter of "Don't be silly, or the archive admins will reject it from NEW"
[21:23] <RainCT> joaopinto: Looking at package names on Synaptic, I guess with 50 characters you'll be save.. (But I'm just guessing!)
[21:23] <joaopinto> ok, i'll use 80 just in case
[21:25] <maxb> libmaypole-plugin-authentication-usersessioncookie-perl is 55 chars :-)
[21:26] <maxb> and 1.9.1~b3~hg20090205r23182+nobinonly-0ubuntu1 is the longest version string, at 44 chars!
[21:27] <joaopinto> ouch, i need to increase the version len
[21:28] <maxb> whilst the longest Source field is "openoffice.org-dictionaries (1:3.0.1~rc1-3ubuntu1)" at 50 chars
[21:37]  * porthose kicks his router for being a pain in the arse
[21:37] <porthose> sorry for the noise
[21:40] <RainCT> porthose: bah, I've done worse monologues ;)
[21:45] <c_korn> as I see scilab was uploaded again. where can I see it waiting for building?
[21:46] <porthose> RainCT: it's getting a little old, probable need to replace it;-)
[21:52] <RainCT> c_korn: https://edge.launchpad.net/ubuntu/+source/scilab
[21:52] <RainCT> c_korn: click on the version number and perhaps some other links and you'll end up at a page with info about the build
[21:53] <c_korn> RainCT: ah thanks. I did not find the link to launchpad.../+source
[21:54] <Laney> nice work huats! (py-webkit-gtk)
[21:54]  * Laney waits expectantly for a build
[22:04] <mok0> c_korn: https://edge.launchpad.net/ubuntu/jaunty/+builds?build_text=scilab&build_state=all
[22:04] <mok0> c_korn: still pending
[22:05] <c_korn> mok0: I see. it should build fine now (hopefully)


[00:39] <greearb> I have what may be a squashfs bug in ubuntu 8.0.4:  I am building a custom image, and when I view certain files inside of the chroot, everything looks fine.
[00:40] <greearb> But, when I make a squashfs and iso image, and then mount that with -o loop, certain files in squashfs image give IO errors when I try to read them.
[00:40] <greearb> I am not sure this is anything other than bad luck, but the files are: /var/lib/scrollkeeper/TOC/16544 - 1651
[00:41] <greearb> I have not found any others, but it's possible they exist.
[00:41] <greearb> I'm open to suggestions if anyone has any ideas on how to further debug this
[02:24] <newz2000> ok, confirmed. `/etc/init.d/kvm stop` did allow virtualbox to run
[02:24] <newz2000> thanks for the help
[07:56] <elmargol> Someone knows how I get the virtualbox 1.6 module running on the current ubuntu version
[13:39] <rtg__> Ng: http://ppa.launchpad.net/timg-tpi/ubuntu has the e1000 eeprom patch.
[13:39] <Ng> rtg__: thanks
[15:04] <emgent> heya
[16:21] <Riddell> linux-image-2.6.25-1-386, main or universe?
[17:04] <BenC> amitk, rtg__, cking, pgraner: ping
[17:05] <cking> Hi
[17:05] <BenC> Riddell: universe
[17:06] <BenC> Riddell: all other packages from linux-ports are main
[17:06] <rtg__> BenC: pong
[17:07] <pgraner> BenC: pong
[17:08] <amitk> BenC: pong
[17:08] <BenC> Ok, the ubuntu-kernel-team meeting is now in session
[17:09] <BenC> No real agenda is in order, but just to update on the status for intrepid...
[17:10] <BenC> linux-ports => New package, uploaded and built already. This package contains all the architectures/flavours that are community supported
[17:10] <BenC> This basically means != i386/amd64
[17:11] <BenC> With the exception of the -386 flavour, which is mostly kept for things LTSP
[17:11] <BenC> *like LTSP
[17:11] <BenC> It's 2.6.25 based, and will probably remain that way for intrepid
[17:12] <BenC> The community port teams are expected to maintain proper configs and patches in that package
[17:12] <amitk> BenC: I recall Oliver (ogra) mentioning that LTSP used -generic now. rtg__ do you remember?
[17:12] <rtg__> amitk: yep - all default installs use generic.
[17:13] <BenC> amitk: some of the older hardware uses -386, but it's an option, not the default
[17:14] <BenC> There are some LTSP boxes that fit in the palm of your hand, which use the -386 kernel (at $100 a box, they are economical)
[17:14] <amitk> ok
[17:14] <BenC> atleast I remember being told that, hehe
[17:15] <BenC> Next, we have some UDS topics that will affect the kernel maint infrastructure...
[17:15] <rtg__> ogra said that there are no modern LTSP devices that _require_ -386.
[17:15] <BenC> linux-ubuntu-modules is moving to the main linux source tree (in our git, not upstream)
[17:16] <BenC> This will be done by placing the third party modules in an ubuntu/ subdirectory, and should alleviate problems we've had with separate ABI/headers for third party modules
[17:16] <BenC> (e.g. alsa)
[17:16] <BenC> This is the same way we did things prior to feisty
[17:17] <BenC> linux-backports-modules will remain the same
[17:18] <BenC> linux-restricted-modules will get a huge face lift. First, fglrx and nvidia will be moved to DKMS packaging, to remove the need to update them on ABI bumps (recompiles of the kernel module will happen on the local machine)
[17:19] <BenC> Next, we'll ditch a lot of old drivers that are unused, and we'll perform the usual driver refresh...linux-restricted-modules will then be converted to use the same build infrastructure as lbm/lum/linux
[17:19] <rtg__> You can read the UDS discussion results at https://wiki.ubuntu.com/KernelTeam/UDS/May2008. I should have published this awhile ago.
[17:20] <BenC> lbm and lrm will only support the main architectures (x86/x86_64)...port maintainers should create their own infrastructure for third-part/restricted modules
[17:21] <BenC> Considering that most hardware related to the ports are supported in the kernel, I don't see this being a problem
[17:21] <BenC> The only exception being aufs, which ports will need if they want a livecd for their architecture
[17:22] <BenC> The other major change, is that what we used to have as binary-custom in-tree builds (xen/rt) will be moved to external packages, which will build-dep and patch linux-source-2.6.xx to build their respective binaries
[17:22] <BenC> The same will happen to -virtual
[17:23] <BenC> rtg__: Thanks, that should fill in some gaps for questions
[17:23] <BenC> So, that leaves i386=>generic,server and amd64=>generic,server as the only things left in the main kernel tree
[17:24] <BenC> We are hoping that narrowing our scope will improve our focus and quality on supported architectures
[17:24] <BenC> Any questions?
[17:25] <BenC> Anything anyone wants to add to the discussion?
[17:25] <BenC> Meeting adjourned then :)
[17:25] <maks_> i'd have 2 points
[17:26] <BenC> maks_: Ok, just in time...whatcha got?
[17:27] <maks_> 1) the SAUCE patches, i guess those are on the way to upstream?
[17:27] <rtg__> maks_: most of them.
[17:27] <BenC> maks_: Actually, some are pushed upstream, and others will never be accepted
[17:27] <BenC> and some are in progress...SAUCE will be a never ending endeavor
[17:28] <maks_> 2) initramfs-tools sync
[17:28] <maks_> as sauce is rebased should be easy to submit the blacklist ones
[17:28] <BenC> maks_: the initramfs-tools sync should be done as part of our normal merge-o-matic from Debian
[17:29] <BenC> maks_: but I'll be sure to give it personal attention :)
[17:29] <BenC> maks_: Is there anything we have locally in ubuntu that isn't merged in Debian?
[17:29] <maks_> yep
[17:29] <BenC> Do you know what they are off-hand?
[17:29] <maks_> 1sec
[17:30] <maks_> firmware detection differs
[17:30] <maks_> mountroot fail hooks
[17:30] <maks_> loop support
[17:31] <BenC> maks_: meaning we have loop support and debian doesn't?
[17:31] <maks_> old ps3 support
[17:31] <maks_> the old ps3 stuff that didn't go into linux-2.6
[17:32] <maks_> BenC: yes
[17:32] <BenC> right, but we released ps3 support, so we need to maintain that backwards compatibility
[17:32] <maks_> sure but not in hardy irc
[17:32] <BenC> we can probably ditch it in intrepid
[17:33] <maks_> trigger support landed
[17:33] <BenC> gutsy was first release with old driver names, hardy maintained for upgrades, and intrepid can ditch them
[17:34] <maks_> MODULES=dep got /sys walking logic in debina
[17:34] <maks_> plus bunch of nfs root fixes
[17:34] <BenC> nice
[17:34] <BenC> maks_: Ok, I'll personally review the initramfs-tools sync
[17:35] <maks_> ok cool
[17:35] <maks_> Luke was helping out for merging bits and pieces
[17:35] <maks_> but seemed silent lately
[17:35] <maks_> once sync happen i'll see what i can do on my side to reduce too
[17:36] <BenC> Sure thing....ok, so _now_ meeting is adjourned
[17:36] <maks_> :)
[17:36] <maks_> cya
[17:36] <BenC> Thanks everyone
[17:36] <BenC> maks_: thanks
[18:03] <infinity> rtg__, BenC : I just read scrollback, and when Ogra said "we use -generic by default and I get no complaints", he and I later discussed that further and, yes, the 386 kernel flavor is still required, even if not the default.
[18:04] <infinity> rtg__: I meant to catch up with you that same day in Prague (when we also did the 486/586 toolchain discussion), but didn't get around to it. :)
[18:04] <rtg__> infinity: there are LTSP devices that are not i586 or better?
[18:05] <infinity> rtg__: There's no such thing as an "LTSP device" but, yes, plenty of people are running LTSP on 486-class hardware still.
[18:06] <rtg__> infinity: do you think the community port for -386 is sufficient for those users?
[18:06] <infinity> rtg__: We have two distinct (and very different) target markets for LTSP installations.  The corporate thin-client users are all on reasonably new and speedy hardware (and they'll also be keen on us finally having ARM support), and then the "poor schools and communities recylcing hardware as terminals" have a lot of older kit lying around.
[18:07] <infinity> rtg__: If -386 moves to linux-ports, that should be fine.  It just shouldn't go away entirely.
[18:07] <rtg__> infinity: ok, then I think we're fine. We did not plan to remove -386, only move it.
[18:08] <infinity> rtg__: Kay.  In Prague, it sounded more like outright removal.  Not like adding it back would be hard, but... Best not to remove it in the first place. :)
[18:09] <rtg__> infinity: to be honest, it was my original intention to remove it. I quickly changed my mind :)
[18:23] <esox> Hi, when one compiles a vanilla kernel do one need to apply patches ? I eared about ubuntu patches
[18:24] <rtg__> esox: start here: https://wiki.ubuntu.com/KernelMaintenance
[18:26] <esox> rtg__: is this how to compile vanilla kernels ? because I want to build a 2.6.25-rt kernel... I did it but no wifi, no alsa, and gdm start issues
[18:27] <esox> the systems starts but with those issues
[18:27] <rtg__> esox: that page describes how to build the Ubuntu kernel. For other stuff you're on your own.
[18:28] <esox> rtg__: ok... so you dont know if there are ubuntu patches available somwhere ?
[18:29] <rtg__> esox: there are no patches for 2.6.25, but there are a number in the Ubuntu kernel git repository for 2.6.24.
[18:29] <esox> rtg__: cool, thanks
[18:29] <esox> I go for that
[18:29] <maks_> esox: start from a working .config
[18:30] <esox> maks_: you mean re-build a 2.6.22-rt as a beginning ?
[18:30] <maks_> no
[18:31] <maks_> you probably goffed on .config settings thus go from a working /boot/config-2.6.24-whatever
[18:32] <esox> maks_: I'm on gutsy ubuntustudio, so it's 2.6.22 and that version
[18:33] <maks_> a lot happened since, anyway good luck
[18:33] <esox> maks_: well i have too many issues with 8.04...
[20:00] <rtg__> BenC: did you want that mmc fix in Hardy before I upload?
[21:23] <Bari_> anyone have any idea why a <IP_ADDRESS> kernel may have problems initializing and assigning irq's to VIA USB controllers? irq's get assigned and the get disabled since "nobody cared"   cat /proc/interrupts show  10:     100000    XT-PIC-XT        uhci_hcd:usb3, uhci_hcd:usb4   11:     100000    XT-PIC-XT        uhci_hcd:usb1, uhci_hcd:usb2   seconds after booting,  serial debug output: http://pastebin.com/m3320b15f
[22:15] <BenC> rtg__: does it apply to hardy? If so, yes
[22:15] <rtg__> BenC: already done and pushed.


[11:54] <BrisBen> hello, just came to say nice podcast, keep it up.
[23:42] <amurray> good morning
[23:43] <amurray> thanks for the nice words BrisBen - shame you disconnected before I could tell you directly.. :)


[08:58] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (bionic-proposed/main) [2.525.29 => 2.525.30] (desktop-core)
[08:58] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.50 => 2.408.51] (desktop-core)
[08:58] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.7 => 2.578.8] (desktop-core)
[09:19] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-163.191] (core, kernel)
[09:21] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (xenial-proposed/main) [4.15.0-1043.45] (kernel)
[09:26] -queuebot:#ubuntu-release- New: accepted linux-signed-gcp [amd64] (xenial-proposed) [4.15.0-1043.45]
[09:26] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-163.191]
[09:43] -queuebot:#ubuntu-release- Unapproved: kdeplasma-addons (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
[09:43] -queuebot:#ubuntu-release- Unapproved: ksysguard (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
[09:44] -queuebot:#ubuntu-release- Unapproved: kwin (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:<IP_ADDRESS>-0ubuntu0.1] (kubuntu)
[09:44] -queuebot:#ubuntu-release- Unapproved: milou (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
[09:46] -queuebot:#ubuntu-release- Unapproved: plasma-desktop (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:<IP_ADDRESS>-0ubuntu0.1] (kubuntu)
[09:46] -queuebot:#ubuntu-release- Unapproved: plasma-workspace (bionic-proposed/universe) [4:5.12.8-0ubuntu0.1 => 4:5.12.9-0ubuntu0.1] (kubuntu)
[09:46] <RikMills> sil2100: New plasma SRU for bionic ^^. You'll be please to see that this time due to the very small number of sources with changes worth having, I have cherry-picked just 6
[09:48] <sil2100> RikMills: I like such new upstream releases!
[09:51] <RikMills> sil2100: I thought as much! Plasma 5.12 also now goes in emergency bugfix mode only. no new 'scheduled' releases
[11:01] -queuebot:#ubuntu-release- Unapproved: accepted kdeplasma-addons [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
[11:07] -queuebot:#ubuntu-release- Unapproved: accepted ksysguard [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
[11:11] -queuebot:#ubuntu-release- Unapproved: accepted kwin [source] (bionic-proposed) [4:<IP_ADDRESS>-0ubuntu0.1]
[11:17] -queuebot:#ubuntu-release- Unapproved: accepted milou [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
[11:18] <slashd> o/ sil2100, (re: lp1843036) all good on my side if it's still okay for an early release.
[11:19] <sil2100> slashd: excellent
[11:19] <sil2100> slashd: will proceed in a moment
[11:19] <slashd> sil2100, thanks
[11:19] -queuebot:#ubuntu-release- Unapproved: accepted plasma-desktop [source] (bionic-proposed) [4:<IP_ADDRESS>-0ubuntu0.1]
[11:26] <sil2100> slashd: btw. wanted to poke you about LP: #1838771
[11:26] <sil2100> slashd: Julian verified it via the autopkgtest, but before proceeding I would like you - if possible - to confirm the fix is working at least for one series
[11:27] <sil2100> On a closer-to-real environment
[11:27] <sil2100> Of course if it's not easily doable, I can accept things as they are if you're fine with it as well
[11:33] <slashd> sil2100, let's see if I can recreate the issue easily, I'll ping you in a couple of mintes
[11:33] <slashd> minutes ^
[11:34] <sil2100> slashd: thanks!
[11:39] <slashd> sil2100, look good to me with testing the test case
[11:40] -queuebot:#ubuntu-release- Unapproved: accepted plasma-workspace [source] (bionic-proposed) [4:5.12.9-0ubuntu0.1]
[11:40] <rbalint> sil2100, could you please merge this for next systemd upload?: https://code.launchpad.net/~rbalint/britney/autopkgtest-eoan-hints/+merge/372682
[12:02] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2.3]
[12:03] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (bionic-proposed) [2.3-3ubuntu9.6]
[12:15] <RikMills> sil2100: wow. thank you for the quick turnaround on plasma. I was genuinely not expecting that until maybe next week
[12:20] <slashd> thanks sil2100 for net-snmp and apt.
[12:22]  * Laney wants to join in
[12:22] <Laney> thanks sil2100!
[12:27]  * sil2100 feels bad now that he didn't do anything for Laney today but still got thanked
[12:27] <sil2100> slashd, RikMills: yw!
[12:27] <sil2100> Laney: need anything by any chance? ;p
[12:27] <Laney> haha
[12:27] <Laney> no, there's no debt system here
[12:27] <sil2100> rbalint: on it
[13:34] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (bionic-proposed/main) [5.0.0-1019.20~18.04.1] (kernel)
[14:59] <rbalint> sil2100, could you please check this, too? LP: #1843755
[15:00] <sil2100> rbalint: will try, but not sure if I'll have the capacity today
[15:00] <rbalint> sil2100, thanks, no problem
[15:11] <vorlon> ok so I'd seen a number of packages ftbfs when trying to do a naive drop of python2 because the distutils buildsystem required the python2 'pyversions' command - but python-openstackdocstheme dropped python2 in this way, and builds fine from source in Debian
[15:11] -queuebot:#ubuntu-release- New: accepted linux-signed-azure [amd64] (bionic-proposed) [5.0.0-1019.20~18.04.1]
[15:11] <vorlon> anyone know what we're missing between sid and eoan for this and if it's safe to copy?
[15:12] <vorlon> looks like there's a new debhelper in unstable
[15:12] <doko> missing dh-python b-d?
[15:13] <vorlon> no; dh-python doesn't pull in python / pyversions
[15:13] <vorlon> and the build-dep is there
[15:13] <vorlon> and the same package builds fine in sid, *not* in eoan
[15:19] <vorlon> oh wait, pull-lp-source gave me the wrong version; let me retest this
[15:25] <vorlon> ok, yeah, the Debian maintainer worked around this by neutering the dh_auto_* targets in debian/rules
[15:37] <rbasak> sil2100: fyi, I'm reviewing libvirt in the Bionic SRU queue - carried over from yesterday, and I have the context from the previous qemu review
[15:37] <rbasak> If it looks good I'll accept it today
[15:39] <sil2100> rbasak: ok, thanks for the heads up! I'm done with my shift for today I guess
[15:45] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.13]
[15:47] <didrocks> is there any issue in ppa uploads? /me tried 15 minutes ago to upload something to a ppa and no email of accept/denial
[15:48] <didrocks> (retried to reupload 5 minutes ago -> nothing here)
[15:50] <cjwatson> didrocks: should ask that in #launchpad
[15:51] <didrocks> right, sorry cjwatson
[15:51] <cjwatson> didrocks: but looks like a keyserver outage
[15:51] <didrocks> cjwatson: thanks, keep me posted if I need to reupload
[15:52] <cjwatson> I'll get the failures reprocessed once stuff's back
[15:53] <didrocks> perfect, thanks
[16:28] <rbalint> sil2100, maybe vorlon could take a look at the systemd FFe above?
[16:33] <vorlon> rbalint: launchpad is timing out on me, but I'm in the process of trying to comment and mark the bug incomplete, because I don't think your FFe request includes compelling rationale for why this is an important update, nor analysis wrt the actual upstream changes about what the risks are of this update
[16:33] <vorlon> ok, now the comment has gone through
[19:04] <vorlon> coreycb: https://people.canonical.com/~ubuntu-archive/nbs.html is looking excitingly short now; don't know if it's worth revisiting python-pbr revdeps for 19.10?
[19:10] <coreycb> vorlon: oh yeah that's looking a whole lot better
[19:11] <coreycb> vorlon: realistically we will probably punt pbr until next cycle unless we get pushed to do it this cycle
[19:11] <vorlon> fair enough
[19:12] <coreycb> vorlon: thanks again for helping me with all the proposed migrations
[19:13] <vorlon> sure thing
[19:27] <LocutusOfBorg> vorlon, hello, I finally fixed nbsphinx, the package regressed because of pandoc
[19:27] <LocutusOfBorg> unfortunately it needs a little tiny python script to work, and I uploaded it in Debian new and Ubuntu
[19:27] <LocutusOfBorg> https://launchpadlibrarian.net/442049218/sphinxcontrib-svg2pdfconverter_0.1.0-1~ubuntu1_source.changes
[19:27] -queuebot:#ubuntu-release- New source: sphinxcontrib-svg2pdfconverter (eoan-proposed/primary) [0.1.0-1~ubuntu1]
[19:28] <LocutusOfBorg> I would appreciate if you could have a look, it is made of two python scripts, that calls imagemagick and friends to convert svg to png
[19:28] <LocutusOfBorg> https://ftp-master.debian.org/new/sphinxcontrib-svg2pdfconverter_0.1.0-1.html
[20:00] <sergiusens> is there a way to get reverse/test deps autopkgtests to get redone with a newer package (ref: snapcraft -> ubuntu-image to use the newer ubuntu-image)
[20:06] <vorlon> sergiusens: click the 'retry' button, given that current ubuntu-image is in the release pocket
[20:07] <vorlon> (the 'recycle' icon)
[20:08] <LocutusOfBorg> we should probably rekick automatically tests if the package in question has migrated...
[20:10] <vorlon> no
[20:10] <vorlon> because the previous test wouldn't have had ubuntu-image as the trigger
[20:12] -queuebot:#ubuntu-release- New: accepted fwupdate [sync] (eoan-proposed) [12-6]
[20:12] -queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [sync] (eoan-proposed) [10-1]
[20:12] -queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [sync] (eoan-proposed) [1.1.0-1]
[20:12] -queuebot:#ubuntu-release- New: accepted rust-c2-chacha [sync] (eoan-proposed) [0.2.2-1]
[20:18] -queuebot:#ubuntu-release- New: accepted sphinxcontrib-svg2pdfconverter [source] (eoan-proposed) [0.1.0-1~ubuntu1]
[20:19] <LocutusOfBorg> vorlon, I mean, if there is a failing autopkgtest about a version of a package that is outdated, because a new version is in release, can't we just automatically retry the test?
[20:19] <LocutusOfBorg> the trigger changes, but at least we have a fresh run against the new "baseline" in release pocket
[20:19] <LocutusOfBorg> I know, something else might change and break/fix it, not the package itself...
[20:20] <LocutusOfBorg> like firewalld, it is not triggered on nftables updates, but each time nftables is updated... it breaks
[20:20] <LocutusOfBorg> I wish we had a way to force tests in some way
[20:20] <LocutusOfBorg> thanks for accepting the stuff!
[20:27] <vorlon> so the long-term plan is to have rolling baseline re-tests of everything in the archive
[20:27] <vorlon> but that would test against the release pocket *only*, it wouldn't help a new snapcraft in -proposed migrate
[20:28] <vorlon> and we shouldn't automatically retest a package in -proposed with a failing autopkgtest every time one of its dependencies updates in the release pocket
[20:57] -queuebot:#ubuntu-release- New binary: llvm-defaults [amd64] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
[20:57] -queuebot:#ubuntu-release- New binary: llvm-defaults [ppc64el] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
[20:57] -queuebot:#ubuntu-release- New binary: llvm-defaults [i386] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
[20:57] -queuebot:#ubuntu-release- New binary: llvm-defaults [arm64] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
[20:57] -queuebot:#ubuntu-release- New binary: llvm-defaults [s390x] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
[20:58] -queuebot:#ubuntu-release- New binary: llvm-defaults [armhf] (eoan-proposed/universe) [0.48.2ubuntu1] (no packageset)
[20:59] <sergiusens> thanks vorlon
[20:59] <sergiusens> wasn't sure that would cause the desired effect as the line with the failure explicitly mentions the previous version of the package was used
[21:05] -queuebot:#ubuntu-release- New binary: fwupdate [amd64] (eoan-proposed/universe) [12-6] (lubuntu)
[21:05] -queuebot:#ubuntu-release- New binary: fwupdate [armhf] (eoan-proposed/universe) [12-6] (lubuntu)
[21:05] -queuebot:#ubuntu-release- New binary: fwupdate [i386] (eoan-proposed/universe) [12-6] (lubuntu)
[21:05] -queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [i386] (eoan-proposed/universe) [1.1.0-1] (no packageset)
[21:05] -queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [s390x] (eoan-proposed/universe) [1.1.0-1] (no packageset)
[21:05] -queuebot:#ubuntu-release- New binary: ocaml-stdcompat [s390x] (eoan-proposed/universe) [10-1] (no packageset)
[21:05] -queuebot:#ubuntu-release- New binary: ocaml-stdcompat [amd64] (eoan-proposed/universe) [10-1] (no packageset)
[21:05] -queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [ppc64el] (eoan-proposed/universe) [1.1.0-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: fwupdate [arm64] (eoan-proposed/universe) [12-6] (lubuntu)
[21:06] -queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [amd64] (eoan-proposed/universe) [1.1.0-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [armhf] (eoan-proposed/universe) [1.1.0-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: ocaml-stdcompat [armhf] (eoan-proposed/universe) [10-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: ocaml-stdcompat [ppc64el] (eoan-proposed/universe) [10-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: ocaml-stdcompat [arm64] (eoan-proposed/universe) [10-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: ocaml-charinfo-width [arm64] (eoan-proposed/universe) [1.1.0-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: ocaml-stdcompat [i386] (eoan-proposed/universe) [10-1] (no packageset)
[21:06] -queuebot:#ubuntu-release- New binary: sphinxcontrib-svg2pdfconverter [amd64] (eoan-proposed/universe) [0.1.0-1~ubuntu1] (no packageset)
[21:11] -queuebot:#ubuntu-release- New: accepted fwupdate [arm64] (eoan-proposed) [12-6]
[21:11] -queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [arm64] (eoan-proposed) [1.1.0-1]
[21:11] -queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [arm64] (eoan-proposed) [10-1]
[21:11] -queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [i386] (eoan-proposed) [10-1]
[21:11] -queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [amd64] (eoan-proposed) [1.1.0-1]
[21:11] -queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [armhf] (eoan-proposed) [10-1]
[21:11] -queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [armhf] (eoan-proposed) [1.1.0-1]
[21:11] -queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [ppc64el] (eoan-proposed) [10-1]
[21:12] -queuebot:#ubuntu-release- New: accepted fwupdate [amd64] (eoan-proposed) [12-6]
[21:12] -queuebot:#ubuntu-release- New: accepted fwupdate [i386] (eoan-proposed) [12-6]
[21:12] -queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [ppc64el] (eoan-proposed) [1.1.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [amd64] (eoan-proposed) [10-1]
[21:12] -queuebot:#ubuntu-release- New: accepted fwupdate [armhf] (eoan-proposed) [12-6]
[21:12] -queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [s390x] (eoan-proposed) [1.1.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted ocaml-charinfo-width [i386] (eoan-proposed) [1.1.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted ocaml-stdcompat [s390x] (eoan-proposed) [10-1]
[21:44] -queuebot:#ubuntu-release- New: accepted sphinxcontrib-svg2pdfconverter [amd64] (eoan-proposed) [0.1.0-1~ubuntu1]
[22:58] <vorlon> jamespage: you were the last uploader of python-ibm-db-sa (in 2015) which is python2-only and removed in Ubuntu. any reason to keep it?


[19:10] <valorie> Mamarok: usually all is well. system76 has a great PPA to make sure everything is right
[19:49] <Mamarok> nah, I read too many horror stories from users on IRC and the forums, I can live without that
[21:37]  * valorie loves her laptop
[21:37] <valorie> best yet


[08:15] <bkerensa> pleia2: you beating me in steps :s
[08:15] <bkerensa> pleia2: :) I got a Flex today


[06:15] <Satyam2345> https://t.me/plasmamobilehttps://t.me/plasmamobile
[06:15] <Satyam2345> https://t.me/plasmamobile
[06:16] <Satyam2345> ^want to change team
[06:18] <Satyam2345> plasma-mobile , another effort for gnu/linux on mobile
[08:20] <Lele_> Can i install ubuntu touch on samsung e500 smartphone?
[09:57] <xenialarm> ok first ssh telnet and http work for building buold-essential
[09:58] <xenialarm> but vnc says there is a port problem
[09:58] <xenialarm> not sure what that is about
[09:59] <xenialarm> i tried xrdp and it fails too  .. do i need to install freerdp
[10:04] <xenialarm> this linux deploy for cheap hardware is a little difficult to get going compated to gnuroot for debian wheezyx
[10:04] <xenialarm> but anyway some of ubuntu is working
[10:05] <xenialarm> at least gcc and g++ are workinf
[10:06] <xenialarm> and ircchat obviously works
[10:08] <xenialarm> because millions of people are demanding that all digital hardware and software be free .. especially the little kids and also people that like to acquire low and sell high
[10:18] <xenialarm> nothing to touch right now ad vnc and rdp wont access lxde except of course the hacks 'r us virtual keuboard
[10:19] <xenialarm> keyboard works if u can ever hit the right krys
[10:19] <xenialarm> keys
[10:21] <xenialarm> this rdp and vnc issue is much discussed on the internet but i did not see any solutions yet
[10:24] <xenialarm> and without x i cant figure out how to scroll the user list in this room
[10:32] <xenialarm> is this still connected
[10:32] <xenialarm> still tryong
[10:33] <xenialarm> trying to figure out how to scroll user list
[13:56] <TartanSpartan> Hi anyone got a Pro 5?
[15:12] <aiyion> Suppose the answer is yes, considered the sheer count of people in here.
[15:21] <TartanSpartan> I want to ask some questions of an owner of the phone.
[15:32] <aiyion> And everyone knows that now. So everyone can say, "hey welcome Tartan; youre using irc wrong.".
[15:33] <aiyion> What you want are answers to your actual problem.
[15:33] <aiyion> So go ahead and ask what you want to know instead of wasting time on smalltalk you never going to meet again.
[15:33] <TartanSpartan> I don't have a problem, I'm curious about the specs.
[15:34] <aiyion> saves your time, saves theirs, evrybody back to business and so on.
[15:34] <TartanSpartan> I want to know if it has full USB C speeds.  It puzzles me as to why Meizu switched to USB C ports for the phone yet didn't leverage the full speeds available.
[15:38] <aiyion> because type c is only a form factor
[15:38] <aiyion> have a look at it on your own:
[15:39] <aiyion> https://forum.meizufans.eu/topic/3992/usb-type-c-question/5
[15:40] <thepeter> TartanSpartan, as aiyion said form doesn't make automatically spped :)
[15:41] <TartanSpartan> Was there anything holding back the hardware of the phone in this regard?
[15:50] <aiyion> probably.
[16:09] <TartanSpartan> Anyone know if the phone can handle unconventional devices such as USB Ethernet adapters?
[17:01] <dobey> TartanSpartan: most device drivers are not compiled into the kernel (nor is module support), so most devices won't work, but some will such as generic HID, and maybe some ethernet but i suspect most won't
[17:30] <TartanSpartan> Fair enough.
[17:49] <gljoe> i tried manually  activating x and setting env display=0 and start
[17:50] <gljoe> startlxde but get gtk warning errors about x ...any ideas
[17:53] <gljoe> getting ubuntu x to work seems to be an issue not encountered with wheezyx
[17:55] <gljoe> however the gnuroot approach doesnt let you install and deploy various kernel modules
[17:58] <gljoe> and really nobody wants hardware they cannot use if they wamt to work on kernel ossues
[18:01] <TartanSpartan> Are you on a Xenia channel?
[18:02] <TartanSpartan> Xenial*
[18:03] <gljoe> millions of people especially kids with no money and businesses that like to profit by buying for zero and selling for higher all want that all digital hardware and software be free and free from advertising gimmicks too. no matter how expensive the hardware or software is to make
[18:06] <gljoe> tarrar i dont know if this is a xenia channel  .. people in ubuntu channel said discuss free tlelephone hardware here
[18:08] <gljoe> since the phone is running xenial now or at least some of it
[18:08] <gljoe> not x however
[18:08] <gljoe> or vnc to x
[18:11] <gljoe> at least gcc and g++ are available now bur little else without x
[18:20] <gljoe> whatever i set for display number gtk always says cannot open display
[18:21] <anpok> the phones are running vivid + stable-phone-overlay ppa
[18:21] <anpok> and that ppa got updated all through the development cycle of xenial
[18:25] <gljoe> what is vivid and some ppa repository stuff
[18:26] <gljoe> debian has x working for the apps and it shpuld work on ubuntu also especially for sound apps like audacity
[18:28] <gljoe> do you realize those google sobs try to charge money for sound studio apps
[18:28] <gljoe> on google play
[18:32] <gljoe> the bastards want to give away free hardware but charge for the damn software or steal peoples privacy with data mining and advertizing crap
[19:36] <TartanSpartan> Not sure why he described Ubuntu as "free hardware".
[20:13] <aiyion> even if too late for gljoe:  xapps do work like a charm if one uses libertine
[20:14] <aiyion> have various running.
[20:25] <TartanSpartan> With the recent announcements by Shuttleworth, is switching to Xenial a viable strategy for ordinary users?
[20:43] <dobey> no
[20:44] <dobey> i don't know what that person was trying to do, but it sounds very wrong
[20:49] <TartanSpartan> Can Ubports take over Xenial development for UT devices?
[21:11] <dobey> TartanSpartan: well anyone who still wants to build ubuntu based images for phones is going to have to take on a whole lot more than just the base system i think. lots of the apps in the store just won't work in xenial, and the store will be going away. there will also need to be a lot of development on not just unity8 but all of the pieces of the system which were developed for unity
[21:12] <TartanSpartan> Why will the store go away?
[21:13] <dobey> the click store; why would canonical continue spending money on an app store when they don't make a product which uses it?
[21:13] <dobey> so some other store would have to be set up if you want to use clicks
[21:14] <TartanSpartan> That's very sad :(
[21:14] <dobey> migrating to snaps would be an incredibly daunting task
[21:14] <TartanSpartan> Any idea of a timescale for it's closure?
[21:15] <dobey> i don't know that, no. i presume there will be further announcements in the future
[21:17] <TartanSpartan> I want to replace my MX4 with a Pro 5 but it could take me a long time to afford one. I hope it's still there by that time.
[21:22] <TartanSpartan> Are click apps different for each channel and device? if not, perhaps I could get around the obselecence problem somewhat by backing up all the apps I'm interested in?
[21:25] <dobey> well the ui toolkit has had changes in xenial, and there were binary compatibility issues with gcc5, so arch-dependent apps won't run at all
[21:25] <dobey> webapps (which are most things) should generally be fine, but any golang/c++ scopes/apps will have issues
[21:25] <dobey> otherwise xenial would have been on the phones long ago
[21:27] <dobey> anyway, back to weekend and no irc for me
[21:27] <TartanSpartan> No, I'm not talking about upgrading to Xenial any more. I mean say if I backed up all my Vivid MX4 apps. Could I move them to Pro 5 Vivid and have them all work fine?
[21:27] <TartanSpartan> *Vivid Pro 5
[21:28] <dobey> yes
[21:28] <TartanSpartan> Ah, excellent. Thanks for the advice!


[00:02] <bryce> tjaalton: http://ppa.launchpad.net/bryceharrington/ubuntu/pool/main/x/xserver-xorg-video-intel/
[00:03] <bryce> also at http://people.ubuntu.com/~bryce/Uploads/
[00:03] <bryce> hrm, I wonder how you'd post debdiffs into the ppa?
[00:59] <ubotu> New bug: #197147 in xorg (main) "No gnome desktop after password" [Undecided,Incomplete] https://launchpad.net/bugs/197147
[02:04] <ubotu> New bug: #197158 in xorg (main) "should not have to manually do sudo dpkg-reconfigure -phigh xserver-xorg after upgrade" [Undecided,New] https://launchpad.net/bugs/197158
[02:25] <ubotu> New bug: #197163 in xorg (main) "mathematica 6.0.1 in Hardy" [Undecided,New] https://launchpad.net/bugs/197163
[05:01] <ubotu> New bug: #197182 in linux-restricted-modules-2.6.24 (restricted) "Please upgrade nvidia to 169.12" [Undecided,New] https://launchpad.net/bugs/197182
[08:15] <ubotu> New bug: #197209 in linux-restricted-modules-2.6.24 (restricted) "fglrx + compiz fusion won't resume" [Undecided,New] https://launchpad.net/bugs/197209
[10:19] <ubotu> New bug: #196970 in xorg (main) "keyboard partially fails [Hardy Regression]" [Undecided,Confirmed] https://launchpad.net/bugs/196970
[10:27] <ubotu> New bug: #197198 in xorg (main) "Totem crashes when trying to play anything" [Undecided,Incomplete] https://launchpad.net/bugs/197198
[10:52] <ubotu> New bug: #193559 in linux-restricted-modules-2.6.24 (restricted) "atieventsd crashed with SIGSEGV in XQueryExtension()" [Undecided,Incomplete] https://launchpad.net/bugs/193559
[10:52] <ubotu> New bug: #193878 in linux-restricted-modules-2.6.24 (restricted) "amdcccle crashed with SIGSEGV" [Undecided,Incomplete] https://launchpad.net/bugs/193878
[11:13] <ubotu> New bug: #196288 in xserver-xorg-input-mouse (main) "USB Mice do not work on Dell Precision M6300" [Undecided,Incomplete] https://launchpad.net/bugs/196288
[11:31] <ubotu> New bug: #197242 in xorg (main) "radeon drm locking problem: xorg freezes  with gutsy and radeon 7500" [Undecided,New] https://launchpad.net/bugs/197242
[11:53] <ubotu> New bug: #197230 in xorg "Ubuntu 8.04 alpha 5 won't boot in qemu 0.9.1" [Undecided,Confirmed] https://launchpad.net/bugs/197230
[12:23] <ubotu> New bug: #196858 in xorg (main) "Video not detected Hardy KDE 4" [Undecided,Incomplete] https://launchpad.net/bugs/196858
[12:41] <ubotu> New bug: #197263 in xorg (main) "[hardy] xserver freezes the system" [Undecided,New] https://launchpad.net/bugs/197263
[13:06] <ubotu> New bug: #188452 in ubuntu "Ubuntu in X-org don't detect serial mouse.. (dup-of: 9068)" [Undecided,New] https://launchpad.net/bugs/188452
[14:15] <ubotu> New bug: #197291 in xserver-xorg-video-intel (main) "tty broken after last update of xserver-xorg-video-intel" [Undecided,New] https://launchpad.net/bugs/197291
[15:29] <ubotu> New bug: #196617 in xorg (main) "[Hardy Alpha-5] fglrx log noise if dualhead" [Undecided,New] https://launchpad.net/bugs/196617
[15:31] <ubotu> New bug: #197269 in xorg-server (main) "Xorg crashed with SIGSEGV in free()" [Undecided,New] https://launchpad.net/bugs/197269
[15:44] <ubotu> New bug: #196391 in xorg (main) "2d performance is slower after resume  (acpi S3 sleep)" [Undecided,New] https://launchpad.net/bugs/196391
[15:46] <ubotu> New bug: #196343 in xorg (main) "Selecting nvidia restricted driver kills gnome" [Undecided,New] https://launchpad.net/bugs/196343
[15:48] <ubotu> New bug: #196341 in xorg (main) "System reboot before login GDM" [Undecided,New] https://launchpad.net/bugs/196341
[16:09] <ubotu> New bug: #196277 in xorg (main) "[hardy] keyboard layout switching shortcut doesn't work after reboot" [Undecided,Confirmed] https://launchpad.net/bugs/196277
[16:31] <ubotu> New bug: #196129 in xorg (main) "[hardy] X server does not start on G3 iMac." [Undecided,Confirmed] https://launchpad.net/bugs/196129
[17:06] <ubotu> New bug: #197337 in xorg (main) "[hardy][wish] vmmouse should be default driver on kvm/qemu" [Undecided,Confirmed] https://launchpad.net/bugs/197337
[17:11] <ubotu> New bug: #197339 in xserver-xorg-video-intel (main) "No detection of my S-Video output" [Undecided,New] https://launchpad.net/bugs/197339
[19:31] <ubotu> New bug: #57415 in xorg-server (main) "Inconsistent cut-and-paste behaviour (dup-of: 11334)" [Undecided,Invalid] https://launchpad.net/bugs/57415
[21:11] <ubotu> New bug: #197414 in xorg (main) "Bulgarian phonetic keyboard layout is not the country standard" [Undecided,New] https://launchpad.net/bugs/197414
[21:57] <Q-FUNK> odd
[21:57] <Q-FUNK> they were the ones to invent the phonetic cyrillic keyboard, which is the best thing since sliced bread
[22:06] <Q-FUNK> http://www.jukie.net/~bart/blog/fixing-x-for-geode-lx