[00:03] hi guys - just a word to the wise, something in the latest set of updates for raring is busted. Apper won't download python-pycurl, claims packages are left unconfigured. if you deselct it, something else breaks, etc, ad infinitum, until you're left only upgrading firefox. [00:06] we've never used apper [00:06] try muon [00:08] i've never used muon. i don't even have it installed. i used kpackage until it vanished and apper took over, then carried on with apper :) [00:09] i'll try doing it in a tty - that's solved most things before :) [00:11] and as predicted, that fixed it. [00:11] :P [00:26] ok, that's got most of it fixed. still a little strange though - there's a new kernel in the update, 3.8.0-2, which has been kept back, and I can't figure out why. [00:27] how did you upgrade when it was kept back? [00:27] tty, yofel - apper was being a pain in the privates [00:27] if you ran apt-get upgrade that won't install new kernels, dist-upgrade will [00:28] that'll be why then. [00:28] thanks [00:28] reason: the kernel image is a new package, only the meta package is really *upgraded* [00:28] and "upgrade" won't install anything new [00:30] I hope ndiswrapper will build against 3.8.0-2 :) I never figured out why it wouldn't build against 3.8.0-1 last night [00:32] there a buildlog for the dkms module somewhere which should tell why [00:32] the answer to that is... no. It hasn't. "Bad return status for module build on kernel 3.8.0-2-generic (i686)" [00:32] yeah, just about to take a peek [00:34] http://paste.ubuntu.com/1574501/ [00:37] looks like a problem with the code. I might drop away from 1.58rc1 and go back to 1.58 [00:43] oh this is getting silly. this is trying to build 1.58 [00:43] http://paste.ubuntu.com/1574515/ [00:43] . [00:44] * BarkingFish bangs his head repeatedly against his desk [00:44] possibly something it looks for got removed in 3.8 [00:44] i hope not, or I am permanently screwed [00:45] there is no driver for the ar5523 - without ndiswrapper, i am shot. [00:45] well, someone already filed bug 1106051 [00:45] bug 1106051 in ndiswrapper (Ubuntu) "ndiswrapper-dkms 1.58~rc1-0ubuntu1: ndiswrapper kernel module failed to build" [Undecided,New] https://launchpad.net/bugs/1106051 [00:47] ok, well i'm subscribing to that now - i'll keep watch there [01:16] * BarkingFish happy happy happy happy happy happy happy :D [01:16] I don't need ndiswrapper anymore. [01:17] As of kernel 3.8.0-2-generic, there is now an ar5523 module [01:18] * BarkingFish bounces up and down like a roo on a pogo stick [01:31] hooray for free drivers [01:35] apachelogger, you bet. I've been using ndiswrapper for almost 8 years, and finally a working ar552 driver pops up. I can't deny i'll miss ndiswrapper's little foibles and general pain in the arse-ness, but this is about the best day since I dropped windows 11 years ago. [01:35] *ar5523 [01:36] especially since ndiswrapper's dkms module wouldn't build on 3.8.0-2 - this sorta turned up at the right time [01:49] night guys, i'm out to get some sleep :) 2.50am here :P [03:31] Riddell: it seems that rbelem didn't add the description and I didn't double check [09:21] Riddell: need to use ec2 === yofel_ is now known as yofel [11:41] yofel: are you there? [11:42] more or less yes [11:43] yofel: do you have access to the ec2? [11:43] no [11:43] yofel: ok [11:44] if anything I can get you an account on my server, has reasonable amount of bandwidth, but your sudo permissions would be limited to pbuilder [11:45] yofel: i think Riddell has added a wrong key of mine and i am denied access [11:45] is it even running? [11:45] yofel: not sure [11:45] probably not then [11:45] pm [11:45] phoenix_firebrd: when did you request the instance? [11:46] yofel: if it is not running then how come it can give a key fingerprint [11:46] shadeslayer: hi [11:46] hey :) [11:46] yofel: huzzah, PA3 is up [11:46] almost all of it [11:46] shadeslayer: Riddell gave me naturally as you mentioned [11:46] hm, dunno, I don't know much about ec2 [11:46] phoenix_firebrd: no, I mean *when* [11:46] not to mention [11:46] shadeslayer: \o/ [11:46] since the IP addresses are shared [11:46] shadeslayer: 2 days back [11:47] phoenix_firebrd: probably shut down then [11:47] phoenix_firebrd: it's basically use and throw instances [11:47] once you're done, you shut them down and someone can spin a new instance and it might get the same address [11:47] shadeslayer: I have asked Riddell to add my key and i have 2 keys in launchpad, i think he might have added the wrong one [11:48] shadeslayer: ok [11:48] which is why you get a fingerprint on your konsole, but the fingerprint is different since it's a new instance [11:48] shadeslayer: ok [11:48] with a different ssh instance [11:48] shadeslayer: ok now understand [11:48] :) [11:48] shadeslayer: So we should request Riddell everytime need one [11:49] more or less [11:49] and shut it down once you're done [11:49] shadeslayer: it was a blizz working with a 40 mbps connection [11:49] :D [11:49] one other way to speed up builds is by doing in memory builds [11:50] but then you need alot of RAM for that [11:50] talking abou thtat [11:50] shadeslayer: only thing that is bad for me is i have a 400ms delay in char echo [11:50] heh [11:50] phoenix_firebrd: mosh ftw [11:50] shadeslayer: any idea why eatmydata wouldn't work? [11:51] ya [11:51] i am getting my log filled by it [11:51] yofel: no idea [11:51] I tried to make phoenix_firebrd enable it, but it only kept throwing errors that the so isn't there, even though it seemed installed (from what he said) [11:51] yofel: need the log? [11:52] yofel: its just this "ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignored." [11:52] yofel: did you try making sure LD_PRELOAD had the lib in it's path [11:52] not really [11:52] hm [11:52] shadeslayer: i checked it and it was in the patch [11:52] shadeslayer: if works fine for me, that's why I'm confused [11:52] shadeslayer: and ldd loads it without a problem [11:52] phoenix_firebrd: in the path *inside* pbuilder, right? [11:53] yofel: ya, we checked together, you forgot [11:53] no, just wanted to double check [11:53] as this doesn't make sense [11:53] yofel: let me check it one more time [11:55] the lib is in its path and it ldd shows no problem [11:57] yofel: how do i replace the default editor used by quilt, i put "EDITOR=kate" in quilltrc. thats not working [11:57] what would quilt need an editor for? [11:57] quilt edit ? [11:57] never used that [11:58] heh okay [11:58] phoenix_firebrd: try putting : export EDITOR=kate : in bashrc [11:58] ^ [11:58] shadeslayer: ok [11:58] i will try [12:01] shadeslayer: works [12:01] awesome [12:03] i can see probably in some debian/patches files the original file is in source.orig dir and the new file is in the source dir why is this? [12:03] I usually setup quilt by following : http://www.debian.org/doc/manuals/maint-guide/modify.en.html [12:04] phoenix_firebrd: patch strips out the first part of the path when used with -p1 [12:04] same here, except a few things removed that pinotree said were nonsense [12:04] yofel: oh? like? [12:05] --no-index [12:05] phoenix_firebrd: have a read through the -pnum option in the patch man page [12:05] that was like ages ago though so don't ask me for the reasoning [12:05] heh [12:07] I am not able to understand what you said, i will post the original patch and the new patch created by me take a look at it [12:08] this is the old one -->http://paste.kde.org/657410/ [12:08] this is the new one created my me -> http://paste.kde.org/657422/ [12:09] looks the same [12:09] except it adds an index [12:09] because he has my quiltrc [12:09] heh [12:09] shadeslayer: look at the new and original file locations [12:10] shadeslayer: in the original patch [12:10] same? [12:10] ^ [12:11] shadeslayer: sorry [12:11] i added the wtrong one as original file [12:11] phoenix_firebrd: or did you mean something like this: http://paste.kde.org/657428 ? [12:12] yofel: exactly [12:12] what's what you get if you don't use "-p ab" in quilt diff [12:12] and your quiltrc sets that [12:12] *that's [12:13] yofel: he's talking about the path stripping stuff right? [12:13] yofel: when i uupdate, the default patch files are like this [12:13] shadeslayer: ya [12:14] why fuzz is not allowed patching? [12:14] well, it's the default setting to have it with .orig [12:14] not sure why uupdate would use that though [12:15] not sure, from man 1 dpkg-source: [12:15] Contrary to quilt's default behaviour, patches are expected to apply without any fuzz. When that is not the case, you should refresh such patches with [12:15] quilt, or dpkg-source will error out while trying to apply them [12:16] oh fun, that explains why builds fail when there is fuzz [12:16] wait, you didn't know that? :D [12:16] let's just say I didn't realize that it was documented behavior [12:16] heh [12:16] I thought it was some sort of feature that was missing [12:17] I think it did change at some point [12:17] yofel: here is a build log of texi2html http://paste.kde.org/657434/ do you see anything odd or everything is ok [12:17] as it did with dpkg-source not auto-committing manual changes anymore [12:18] *blink* [12:18] phoenix_firebrd: ok, I think I know what's causing *those* LD errors [12:18] is eatmydata installed in your regular system? [12:18] yofel: let me check [12:19] yofel: no [12:19] yofel: install? [12:19] yeah, that'll probably help [12:19] ok [12:19] as the pbuilder scripts need to run a few commands on the host system (like ln for the debs) [12:20] "Need to get 969 MB/1,088 MB of archives." [12:20] :( [12:20] yofel: should i update pbuilder? [12:20] nope [12:20] shadeslayer: upgrading? ^^ [12:21] yeah [12:21] shadeslayer: I am needing the ec2 for the same purpose [12:21] upgrading after a long time [12:21] about 10-15 days [12:21] phoenix_firebrd: actually I'm upgrading my system :P [12:21] not pbuilder [12:21] oh, now that's a lot then... [12:21] yep [12:22] didn't even upgrade KDE [12:22] so most of it is that [12:22] shadeslayer: some of the apps need some java stuff pre installed before building in the system [12:22] wot [12:22] if you build jar's you will need java... [12:22] anyway, have to go, ciao [12:22] yofel: but he said pre-installed [12:23] no somethink called maven-repo-buildhelper [12:23] yofel: and by pre-installed I infer before dpkg installs build-dep [12:23] *build-deps [12:23] phoenix_firebrd: ^ ? [12:23] ya [12:23] odd [12:23] if maven needs it then it's supposed to pre-depend on java [12:24] yofel: its simple-http [12:24] Pre-Depends ... heh [12:24] doesn't matter, maven is a build system for java, ofcourse it would need java to work [12:24] yofel: this is the package maven_repo_helper [12:25] phoenix_firebrd: what's the problem exactly [12:25] maven-repo-helper does depend on default-jre-headless, does it fail to install? [12:25] yofel: my slow internet connection [12:26] ok [12:26] yofel: then i tried to login to ec2 and failed and i halted building it now [12:28] yofel: the error stop [12:28] yofel: it worked [12:29] good, I forgot about that possibility :/ [12:29] yofel: what does fsync do and by not using that what does get affected? [12:29] yofel: what does fsync do and by not using that what does get affected? [12:29] yofel: what does fsync do and by not using that what does get affected? [12:29] oops [12:30] I am i disconnected? [12:31] fsync flushes any cache buffers to the disk [12:31] tsimpson: thats what i thought [12:32] tsimpson: so is fsync called every 10 sec? [12:34] I think it depends on how much I/O there is, but something like that [12:38] tsimpson: what will happen if i disable fsync? [12:39] tsimpson: data in the buffer will be written only when unmounting and manually flushing? [12:40] phoenix_firebrd: that's my understanding, yes [12:40] and only flushed if the files aren't removed, like they would be when pbuilder is done [12:42] tsimpson: I am working in a desktop with no backup power [12:42] tsimpson: this wont be good for me [12:42] though the kernel will probably flush at some interval [12:42] tsimpson: are you sure? [12:43] tsimpson: is it just for the ext or it applies to all types [12:43] well it only has a finite amount of memory to keep the buffer in [12:43] tsimpson: thats right [12:44] yofel: is it compulsary that the files in the debian/patches to have an extensaion .patch or .diff is ok? [12:45] I can't see it being a problem, it would only effect things run with that LD_PRELOAD in the environment [12:45] so it won't effect the rest of the systems calls to fsync [12:46] tsimpson: ok [12:50] shadeslayer: is it compulsary that the files in the debian/patches to have an extensaion .patch or .diff is ok? [12:59] phoenix_firebrd: sorry, was away [12:59] the files there are named .diff or .patch by convention, as that's what they are [13:00] but you'll see both used. I usually use .diff [13:01] yofel: ok then its time to upload [13:02] phoenix_firebrd: as for fsync. fsync will flush modifications to a file to disk. *Immediately*. It's to tell the filesystem not to wait until it would usually write it to disk [13:02] yofel: wow that cools my head [13:02] dpkg runs fsync a lot to make sure its status database files are in a consistent state after a power failure [13:02] tsimpson: you should note that [13:03] so it runs fsync afer pretty much every modification - several times per package [13:03] in a pbuilder chroot you don't care about consistency, so you don't need fsync either. And disabling it speeds things up a lot [13:04] yofel: nice [13:07] yofel: when you modify the files that i uploaded in my ppa for example the log file do you download, edit and then upload or you just edit it online? [13:09] download, edit, upload [13:09] Launchpad has no online editing feature [13:10] yofel: even when you merge from a branch? [13:11] then I checkout the main branch, and run 'bzr merge " which will merge them locally and then I commit and push [13:12] yofel: what if when you want to edit the changelog before you merge it with the main branch [13:13] bzr merge will do the merge uncommitted so you can edit it before you push it [13:14] yofel: edit offline? [13:15] yes, you do everything on your local system anyway [13:16] yofel: so to confirm, you downloaded from my bazaar branch edited the changelog and then merged with the main, right? [13:16] no, I merged yours, edited the changes and committed the merge [13:17] yofel: ok, thats clear [13:17] merging a branch doesn't mean you're done. It's just imported as one diff until you commit it [13:17] right [13:18] (you only notice that it's a merge from the log) [13:18] yofel: i was confused about the editing thing, i thought you edited stuff online [13:19] ah no. Launchpad has no editor there, so whatever you do has to be done locally [13:19] ok [13:24] yofel: now packages in my ppa are only built for i386, why is this happening? [13:25] does the control file have "Achitecture: all" for the binary package? [13:25] yofel: let me check [13:26] yofel: ya it says "All" [13:26] arch all packages are only built on i386 and can later be used on all [13:26] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture [13:27] it just means that there's nothing architecure-specific in there [13:27] yofel: got it [13:28] yofel: so i should any if i want my package to be built for i386 and amd64 [13:29] right. The usual situation that you have compiled binaries in "any", and things like images, documentation or scripts in "all" [13:30] ok [13:30] *is that... [13:31] ? [13:31] just correcting my sentence [13:33] yofel: is there a deadline to package these http://qa.ubuntuwire.com/uehs/no_updated.html ? [13:33] usually feature freeze, after that you'll need to get an exception for non-bugfix updates [13:34] yofel: no not the schedule , for me? [13:35] that counts for anybody [13:35] yofel: also is anyone else is doing, to avoid work duplication [13:35] updates need to in the archive before feature freeze [13:35] oh right, forgot about that [13:35] the common case is to use update request bugs for that [13:36] look at launchpad for the 'upgrade-software-version' tag [13:37] you'll have to file a bug to request sponsorship for a package anyway unless you know someone that can upload it [13:37] see https://wiki.ubuntu.com/SponsorshipProcess [13:37] yofel: are you talking about the source release schedule or the package schedule ? [13:37] what's the difference? [13:37] schedule is [13:37] !schedule [13:37] A schedule of Raring Ringtail (13.04) release milestones can be found here: https://wiki.ubuntu.com/RaringRingtail/ReleaseSchedule [13:38] the freezes are there and apply to every ubuntu contributor [13:38] yofel: but the title says "Most popular Ubuntu-specific packages that are not in sync with upstream." [13:39] where? [13:39] on the qa page? [13:39] ya [13:39] ok, sorry, I think I lost the original question in the discussion... [13:40] what were you asking again? [13:40] yofel: if you say that the schedule is followed then why are these packages are not not the latest in the repos [13:40] nobody updated them? [13:40] yofel: ok [13:40] updating packages with ubuntu modifications is a manual process [13:41] and there's a limited amount of packagers, and updating packages isn't the only thing to do [13:41] yofel: i thought every package is updated all the time [13:41] well, it depends on who cares about it [13:42] there are dedicated teams for various sets of packages, like us for KDE or mozillateam for firefox and co. [13:42] yofel: so the app maintainer doesn't care about this? [13:42] any packages that don't fall into those catecories in universe are maintained by the MOTU's [13:43] packages in main by the core-devs (main packages all have dedicated maintainers though usually) [13:43] phoenix_firebrd: what app maintainer? [13:43] it's not the upstream developer's job to make sure all hundreds distributions ship his software [13:44] yofel: example the developer of nano doesn't care if it is update in all the distros ? [13:44] and we have no explicit package maintainers in ubuntu like debian does [13:44] that's his decision [13:44] we have plenty of upstream folks poking us in here to please update the packages [13:45] but that's still a rare case compared to the full list of packages [13:45] yofel: good [13:45] ya [13:46] other than that whether a package is updated or not depend on whether an ubuntu-dev notices it and wants to update it [13:47] yofel: is this auto generated or updated by someone? http://qa.ubuntuwire.com/uehs/no_updated.html [13:48] automated I think, but I'm not sure [13:49] yofel: some packages is not the latest in the repos, is that because of the stability taken into account or its not updated simply [13:50] unless there is an update bug mentioning a reason, it's usually latter [13:51] yofel: so if a stable version of the gimp is released today i can package and put it in the beta ppa ? [13:52] ppa sure, but if you want to update it for the archive talk to the desktop team first [13:52] yofel: i am kubuntu beta ppa [13:52] yofel: i am mean kubuntu beta ppa [13:55] a stable version wouldn't belong in the beta ppa, but the update one. [13:55] you would need to be a ninja first anyway to have upload permission. And our PPA's are for KDE related stuff really [13:56] they don't have unlimited space [13:56] Hey all [13:56] yofel: i should put my question like this. why is the gimp not the latest in the normal channel while i have to add a third party ppa to get the latest [13:56] yofel: when i was talking about the ppa , i was talking symbolically [13:56] BluesKaj: hi [13:57] looks up to date to me... [13:57] yofel: no, its just an example [13:57] hi phoenix_firebrd [13:58] well, as long as you own the PPA, you can put in there what you want as long as you don't violate Launchpad's TOS [13:58] yofel: for example when ever a stable digikam version is release, if i want it i have to add some philip ppa to get that [13:59] ah, you shouldn't need that, we try to keep a package for it in our PPA's [14:00] yofel: sorry couldn't understand [14:00] phoenix_firebrd: well, I'm not sure what you're asking. Yes, if you want to put an updated version of digikam in your PPA do it [14:00] we do the same [14:02] yofel: so you mean that if a stable version of digikam is released, it is packaged and put in the update [14:02] well, it's like this: [14:02] if a new digiakm version comes out, someone of us will put an updated package into the development release [14:03] that is then later backported to the current stable release and possible more in our PPA's [14:03] if it's a safe backport, someone will file a backport request so it ends up in -backports [14:04] there isn't really any more than that to it [14:05] yofel: ok [14:05] in what of our PPA's it ends up depends on what kind of update it is. A 2.8.0 -> 2.8.1 update would be bugfix and end up in the updates one. 2.7.0 -> 2.8.0 is something for backports [14:05] the 3.0.0~rc is in the beta ppa [14:07] phoenix_firebrd: note that this is the kubuntu team workflow [14:07] yofel: usually i see in the blog, they say a new stable version is released and they give a ppa to get it, i guess thats a zero hour ppas [14:07] firefox for example as a core package gets full official updates for all supported releases in the archive [14:07] yofel: ya [14:08] yeah, PPA's are the fastest way to get something out [14:08] providing updates in the archive for anything other than the development release takes a while [14:10] yofel: does kubuntu contribute security patches upstream? [14:10] we try to contribute any patches upstream [14:11] yofel: who is the kubuntu security expert? [14:11] I'm not sure whether we have one... [14:12] oh [14:12] Scott is on the release team and usually knows best what CVE's there are [14:15] ScottK: do we have someone that looks at the security issues beside you? [14:19] yofel: http://distrowatch.com/table.php?distribution=kubuntu [14:19] yofel: in this link the version of xz is shown as alpha in 12.10, is that normal? [14:20] yeah [14:20] !info xz-utils [14:20] xz-utils (source: xz-utils): XZ-format compression utilities. In component main, is optional. Version 5.1.1alpha+20120614-1 (quantal), package size 87 kB, installed size 384 kB [14:20] it is a snapshot after all [14:21] yofel: so alpha allowed in main? [14:22] it's the same version as in debian. Maybe dpkg needed some new feature [14:23] yofel: ok [14:23] phoenix_firebrd: it's up to the maintainer, usually you shouldn't do that, but if it has enough value and no critial bugs it's allowed [14:24] yofel: thats out of necessity,ok [14:24] and i would assume that this got plenty of discussion in debian considering it's importance [14:25] ok [14:28] yofel: texi2html is in my ppa, just 1 package in 2 days, because of the republic day holiday and today is sunday. [14:28] 0.5 packages-per-day is far higher than my quota [14:29] but then again I wasted the weekend on python and project neon [14:29] yofel: the project-neon is the best thing [14:30] yofel: my mind is confined to c++ [14:30] yofel: also BASIC [14:30] yeah, better stick to that, the pyhon bindings are a packaging insanity [14:31] :) [14:31] yofel: apper is python [14:32] yofel: muon replaced apper because it was not c++ [14:32] yofel: why is that so? [14:32] omfg I passed calculus [14:32] Quintasan: congrats [14:32] that wasn't really the primary reason, the packagekit apt backend stucking was a more important one [14:32] *sucking [14:33] I HAVE ABSLOLUTELY NO IDEA what did I write there [14:33] Quintasan++ [14:33] yofel: ya, qapt is awesome [14:33] I succesfully calculated one integral and did some deriviatives [14:33] nothing more and I got 12/20 points [14:33] phoenix_firebrd: have fun reading python-qt4-4.9.6/debian/rules : http://paste.kde.org/657524 (very educative ;P ) [14:33]