[00:00] ari-tczew: bug 663925 has now a debdiff for Maverick. I tested it OK [00:00] Launchpad bug 663925 in ncmpcpp (Ubuntu Maverick) "ncmpcpp (version < 0. 5.4) can cause unexpected deletion of files" [Undecided,New] https://launchpad.net/bugs/663925 [00:02] hggdh: I'll have a look tomorrow. [00:02] ari-tczew: cool, and thank you for the ping on it === nhandler is now known as Guest26812 === nhandler_ is now known as nhandler === james_w` is now known as james_w === akoskm is now known as akoskm`away === dotblank-away is now known as dotblank [10:20] micahg, there? [12:00] ari-tczew, can you unsubscribe ubuntu-sponsors fo my bug 694704 [12:01] Launchpad bug 694704 in gnome-icon-theme-blankon (Ubuntu) "Please upgrade gnome-icon-theme-blankon" [Undecided,Confirmed] https://launchpad.net/bugs/694704 [12:01] my mistake :) [12:01] thanks before [12:02] udienz: sponsors unsubsrcibed [12:03] tumbleweed, thanks! [12:04] tumbleweed, about ftbfs at udd.debian.org. all ftbfs must be solved before natty? [12:04] that would be ideal, practically we normally release with a few ftbfs in universe [12:05] tumbleweed, that mean all ftbfs in main is very urgent? [12:06] yes, and the universe ones too, but there aren't enough motus for everything in universe to be perfect [12:08] udienz: can you please forward your gnome-gpg fix to gnome-gpg upstream (they are in launchpad, so you can do a bzr merge request) [12:09] ok done [12:09] that works too :) [12:10] tumbleweed: there are enough motus, but we don't have enough time ;) [12:10] ari-tczew: that means not enough motus :P [12:10] Well, we do have many MOTUs, but not everyone has time [12:11] not enough motus to spend all times to fix ftbfs [12:11] :p [12:11] udienz: yeah, I haven't done any in ages, I've been busy with other stuff [12:11] I have worked here and there since I became MOTU, FTBFS fixing is something which requires patience and time [12:18] udienz: Thank you for your contribution to Ubuntu. :) [12:18] :) [12:37] cdbs: I remember that you started contribution with papercuts fixing. [12:37] ari-tczew: no, my very first upload was a merge [12:38] I began papercut fixing quite later [12:43] cdbs: are you still interested in papercuts? [12:43] ari-tczew: of course I am [12:44] ari-tczew: but I am busy in school work nowadays, see http://blog.expatsinksa.com/?p=59 [12:48] udienz: referring to bug #694985 , it appears that xchat-gnome doesn't use binutils-gold [12:48] Launchpad bug 694985 in xchat-gnome (Ubuntu) "FTBFS xchat-gnome 1:0.26.1-1ubuntu3 in Natty" [Undecided,New] https://launchpad.net/bugs/694985 [12:48] So it would be better if you changed the changelog entry to: [12:48] Fix FTBFS due to ld --no-add-needed [12:49] cdbs: err it doesn't go out of its way to not use gold, gold is the standard linker in natty, isn't it? [12:49] hmm? I don't think so, is it? [12:50] anyway, yes that is a no-add-neded change [12:50] tumbleweed: no it ain't [12:50] it isn't the default builder, its still binutils (the gnu one) [12:51] err, both are GNU, but still ld is being used, not ld.gold . and package binutils-gold is not being installed on build [12:52] g2g [12:58] Hi!! We just released a very stable first version of Wallch .. Please consider of making a review to it --> http://revu.ubuntuwire.com/p/wallch === yofel_ is now known as yofel [13:06] This is the last upload for Wallch version 1. The program is fully checked for bugs and functionality, so a review is really welcome :).. Thanks anyway [13:10] reffering to cdbs' answer, I think that the most efficient Ubuntu development is maintenance QR strategy and looking for new contributors. :) [13:11] looking for new contributors works like snowball effect [13:17] lucas__: udd page seems to be not updated [13:19] tumbleweed: is there any script to prepare clean rebuild? (-Xbuild1) [13:19] ari-tczew: he dosen't rebuild ubuntu that often [13:19] tumbleweed: ah, I thought that this is automatically on machine [13:20] dpkg-source -x; cd foo; dch -l build 'No-change rebuild for foo (LP: #bar)'; debuild -S [13:20] tumbleweed: debuild requires update-maintainer :/ [13:21] the udd ftbfs package should (I assume) only show FTBFSs from the last rebuild where ubuntu hasn't uploaded it since [13:21] s/package/page/ [13:21] err yes, thow an update-maintainer in there [13:21] tumbleweed: hmmm shouldn't rebuild include update-maintainer? [13:22] that's what I'm saying, yes [13:26] tumbleweed: cool it works, thanks. could you make a script for u-d-t? ;) [13:27] ari-tczew: heh, file a request bug, sounds like a vaguely useful thing to have [13:30] tumbleweed: bug 695015 [13:30] Launchpad bug 695015 in ubuntu-dev-tools (Ubuntu) "[wishlist] rebuildpackage script" [Undecided,New] https://launchpad.net/bugs/695015 [13:35] bdrung: ok, got another branch for you. It started as mirror support in syncpackage, and grew legs... [13:41] tumbleweed: can we have an object (SourcePackage) instead? [13:42] bdrung: any particular reason? [13:43] bdrung: you want to combine it with lp/madison related bits? [13:44] tumbleweed: it's easier to understand and to use. __init__ would get the name and maybe the version. a download method would download it... [13:45] tumbleweed: i was thinking about creating a SourcePackage object for sponsor-patch [13:45] bdrung: ok, but that wil lneed lp / madison to determine the component [13:46] tumbleweed: maybe we can should inherit a UbuntuSourcePackage and DebianSourcePackage [13:46] yeah, probably sane [13:47] tumbleweed: either the component is specified on instantiation of lp/madision is used [13:47] I guess I'd better rename it to archives too, then [13:51] tumbleweed: oh! people doing rebuilds without update-maintainer [13:51] tumbleweed: the object can either instantiated with a dsc url or with providing name, version, component. we need a download and extract method. [13:51] tumbleweed: check last milion doko's uploads [13:51] ari-tczew: but the policy requires update-maintainer for rebuilds! [13:52] bdrung: show me this policy [13:52] and tell this one to doko [13:52] ari-tczew: I didn't used to update-maintainer rebuilds either (and people even complained when I *did*), but bdrung then re-read the policy :) [13:52] ari-tczew: https://wiki.ubuntu.com/DebianMaintainerField [13:53] bdrung: [ ] Choice 3: Change Maintainer on any change (including binary rebuild) [13:53] bdrung: but this is "No-change" upload ;) [13:53] ari-tczew: you change debian/changelog [13:53] :P [13:54] bdrung: this is not clear for me. nobody use update-maintainer for rebuilds [13:54] ari-tczew: we can't do binary rebuilds in lp, we can only do source rebuilds [13:54] ari-tczew: the new update-maintainer will update the maintainer field if the target series is not a debian release [13:55] tumbleweed, bdrung: ok, this is not problem for me to use update-maintainer, but there are a couple of people who don't use this command. we should inform them. [13:55] coolbhavi, fabrice IIRC [13:55] if we have changed *anything* in the package, we should update the maintainer. This is why pkgbinarymangler changes the maintianer in the debs it builds, even when they are from pristine debian sources. [13:56] ari-tczew: correct [13:56] tumbleweed: maybe send mass mail to all motus? [13:56] ari-tczew: sounds overkill, rather send a mail to ubuntu-devel [13:57] tumbleweed: there is no guarantee that they will read if you want send mail to listmail [13:57] what's the point? we change maintainer when we do make changes to indicate that original maintainer should not be contacted. no-change rebuild are, by definition, no-change. [13:57] ari-tczew: there's no guarantee they'll do what you say anyway [13:57] we may add a new changelog entry but it doesn't modify package in any meaningful way. [13:58] kklimonda: agreed that it's a relatively minor issue, the big point is that the automated tools should do the right thing. [13:58] ari-tczew: our tools should update the maintainer for rebuilds. if a motu doesn't update the maintainer it's not that problematic thank to the pkgbinarymangler. [13:58] I don't see the point in changing the Maintainer in no-change rebuilds but not in syncs which are sort-of similar [13:59] geser: not in syncs? I don't get it [13:59] tumbleweed, doko ping via emails [13:59] bdrung: the poll isn't specific if the options apply to binary packages and/or source packages [14:00] geser: good point [14:00] udienz: yeah I'm replying [14:00] ari-tczew: when we sync a package, we don't modify the source package maintainer either [14:01] and I don't see a big difference between a sync and a no-change rebuild [14:02] Don't the buildd's mangle the Maintainer field anyway? [14:02] jpds: in the binary, yes [14:02] And that's all that matters. [14:04] geser, tumbleweed, bdrung, jpds: ok what's the conclusion? I want to upload Xbuild1 to fix 2 bugs and dunno whether change maintainer field or not. [14:05] IMHO no change is needed [14:05] +1 [14:05] ari-tczew: both options seems to be ok. [14:06] if you would sync that version right now, the resulting debs would be similar (compared to the rebuild) but didn't have the maintainer change [14:07] i have a strange build failure: "fakeroot debian/rules clean binary" works, but "dpkg-buildpackage" fails. packages: audacious 2.4.2. grab the experimental branch from http://git.debian.org/?p=pkg-multimedia/audacious.git;a=summary [14:07] ok so I'm not changing field [14:08] bdrung: what's the build error output? [14:08] ari-tczew: it fails to link [14:09] ari-tczew: src/libaudtag/util.c:154: undefined reference to `cfg' [14:09] and other undefined references to `cfg' [14:10] bdrung: did you check upstream svn/git for updates? [14:10] ari-tczew: it's their latest release [14:10] last time I fixed one FTBFS related to audacious which I cherry-picked fix from upstream svn [14:11] bdrung: probably the same "LDFLAGS instead of LIBS" error as everything else [14:11] or is it in Maverick? [14:12] Bachstelze: it fails on maverick, too [14:12] and experimental [14:16] bdrung: did you look there? http://hg.atheme.org/audacious-plugins/ [14:17] ari-tczew: audacious, not audacious-plugins [14:18] bdrung: anyway, you know what I mean [14:19] bdrung: from my investigating, only this could be ok: http://hg.atheme.org/audacious/audacious/rev/af52da71e22f [14:19] ari-tczew: yes. src/audacious/audconfig.h hasn't changed in their master branch. [14:20] bdrung: why src/audacious/audconfig.h ? ftbfs looks on src/libaudtag/util.c:154 [14:20] ari-tczew: src/audacious/audconfig.h defines the cfg structure. [14:22] bdrung: and you guess that link which I passed won't fix ftbfs? [14:23] ari-tczew: i'll try it. [14:23] bdrung: I encourage also to try package new upstream release 2.4 [14:24] ari-tczew: 2.4.2 is their latest release and this build failure prevents me from doing so. [14:27] ari-tczew: that patch lets the package compile. [14:27] bdrung: so it fixes FTBFS? [14:27] ari-tczew: yes [14:28] I'm pleased [14:31] bdrung: something to consider with this mirror suport I'm adding is that we lose the security of downloading from https://lp. Do you think we should also pull a dsc from lp for verification? [14:32] tumbleweed: why do we loose the security? [14:33] there's no cryptographic assurance that th edsc you got from your mirror is the same as th eone lp as [14:33] apt checks signed package lists, we aren't using those [14:35] tumbleweed: ok. the verification would be nice. [14:38] tumbleweed: pull dsc from lp and the other files from the mirror. [14:39] tumbleweed: i don't think that we need dget. [14:39] bdrung: seems reasonable [14:40] obviously when a debian package hasn't been imported into lp yet, we can't do that, but that's ok [14:41] tumbleweed: the package should be first in lp and afterwards hit the mirror. otherwise something is really broken [14:41] bdrung: debian package, not ubuntu package [14:42] tumbleweed: oh, yes. [14:42] tumbleweed: can we check debian packages with the debian keyring? [14:43] all udt scripts seem to have been using -u / --allow-unauthenticated, but I think it's perfectly plausible to use the debian keyring [14:43] at least for this corner case [14:45] even with a reasonable amount of pessimism, this job has turned out to be a lot bigger than I expected :/ [14:45] tumbleweed: or better idea: check Release -> check Packages -> download package [14:46] Packages can get quite big [14:46] ok, then it's a bad idea. [14:47] the curse of living in the third world is knowing the sizes of many source packages :) [14:48] then we are at: grab dsc file from launchpad. for packages from debian: if the dsc is not in launchpad, check if the package is signed by the debian keyring. if not give the user a warning and proceed. [14:49] yes, I think that's great (and much better than where we currently are) [14:49] tumbleweed: i have a local mirror of lucid, maverick, natty, testing, and unstable. ;) [14:49] I can't justify the bandwidth costs for that, so I use apt-cacher-ng (but I run a full mirror at my university) [14:51] tumbleweed: i have one offline pc. i sync the complete mirror to an external hard drive, carry the hard drive to the offline pc, and sync the mirror to the pc. then i have access to the complete archive. [14:52] tumbleweed: you pay for the transferred data? [14:53] kklimonda: indeed, 5G caps are standard, I have 25G and pay ~ZAR50 per G after that [14:53] you can get uncapped, but it's generally slow and 3 times the price [14:54] tumbleweed: sounds like fun. not. Where do you live? [14:55] kklimonda: cape town [14:56] ari-tczew: what do you mean? (Re: udd page not updated) [14:56] kklimonda: it's mostly ok, I do big jobs at university or on colo servers. All south africans wait for cheap, fast uncapped broadband :) [14:57] tumbleweed: at least you don't have to worry about snow ;) [14:57] heh, yeah, my car aircon was broken for the last month. it was hell :) [14:58] * bdrung has enough snow. [14:58] lucas__: http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi looks like out-of-date [14:58] * kklimonda still isn't sure whether he'll make it back home tomorrow :/ [14:58] kklimonda: where are you right now? [14:59] at my mother's house, near Bialystok === solarion_ is now known as Solarion [15:01] ari-tczew: define out of date, please [15:01] tumbleweed: You are lucky enough to have the stuff at your univ to run a mirror :D [15:02] lucas__: this page shows FTBFS which were fixed [15:03] cdbs: the mirror is one of the biggest bandwidth users on campus (although mostly after-hours), our IT department hate my guts :) [15:03] cdbs: referring to our discussion ~2 hours ago, I think that the best way to development of Ubuntu is looking for new contributors :) [15:04] cdbs: and I really understand your case with school as I had to limit my time devoted for Ubuntu development due to logistics competition [15:04] hmm [15:05] ari-tczew: of course, new contributors are always welcome === Quintasan_ is now known as Quintasan [15:06] ari-tczew: that's possible, the data isn't live data. the rebuilds are triggered manually from time to time [15:07] lucas__: tumbleweed explained me this case. I thought that there is a special machine which rebuilds all archive periodically. [15:07] ari-tczew: of course not [15:07] cdbs: not what? [15:08] the Ubuntu archive packages need to be manually rebuilt in case of library changes, etc [15:08] ari-tczew: ^ [15:08] cdbs, that is not that obvious :) [15:08] joaopinto: ? [15:09] if there were sufficient resources, rebuilding the entire archive frequently would be proper QA [15:09] of course [15:10] lp has the fascilities for archive-rebuilds, but I haven't seen any in a while [15:10] I was comment just your "of course" :P [15:10] commenting [15:10] okie [15:10] tumbleweed: oh, in case you didn't recognise, I am bilalakhtar [15:11] cdbs: I know who you are :) [15:11] in 100 years from now we are likely to have hw that will rebuild the current entire archive in a few seconds :P [15:12] But the archive would have become bigger by then [15:13] joaopinto: if the size of archive remains constant, then that would be possible in around 20 years [15:13] :P [15:15] tumbleweed: using LP for an archive-rebuild slows down PPA builds for a whole week [15:16] geser: yeah, that's why I noticed them in the past :) 0 priority doesn't seem to be enough [15:29] hggdh: investigaing into your debdiff... I guess that this is SRU, not security issue. is there any case to be hacked due to this bug? [15:58] Any moderator from http://revu.ubuntuwire.com here? [16:25] ari-tczew: I do not think so, upstream is clear on the reason -- in some situations, they were removing .. [16:25] ari-tczew: this is, nevertheless, a security issue -- data loss [16:26] Wallch_Developer: https://launchpad.net/~revu-admins/+members#active [16:36] hggdh: I see no reason to maintenance Applied-Upstream tga if you have tag Origin [16:36] s/tga/tag* === ogra_ac is now known as ogra [17:12] ari-tczew: thank you :) [17:15] does motu do the multiverse repo too [17:27] sagaci: yes [17:27] seems like a pretty big job [17:32] sagaci: that's right [17:35] * kklimonda wonderes how many man-hours are wasted every year by people packaging software. [17:35] wondered... heh [17:35] wonderes even.. heh.. [17:36] ari-tczew: I do not think it is incompatible -- it was applied upstream, but on a newer version; and I did take it from upstream [17:37] kklimonda: could you be more verbosity? [17:37] hggdh: anyway, I gave ACK and subscribed ubuntu-security-sponsors [17:37] ari-tczew: thank you for your help [17:38] kklimonda: s/verbosity/verbose [17:38] hggdh: you're welcome [17:40] ari-tczew: thousands of people work on packaging software for countless distributions - this is pretty much pointless activity in the bigger picture. [17:41] kklimonda: what's your vision of future? [17:41] ari-tczew: wars over scarce resources.. j) [17:42] j) [17:42] hmm [17:42] ;) [17:42] stupid keyboard [17:42] kklimonda: hmm.. merge all distros into one big Linux project? [17:43] merge Debian and Ubuntu => Debuntu or Ubian :> [17:43] ari-tczew: I believe that at some point we'll have to say that Ubuntu is a small dev platform that 3rd party developers develop for. And they release software, deal with bugs, prepare updates etc. [17:44] I'd rather see all but 5 or 6 distributions being abandoned. [17:45] I'm not sure if a merge of debian and ubuntu is something that can happen - but mostly for political reasons, not technical ones. [17:47] kklimonda: maybe you should consider about session at UDS about this case [17:52] kklimonda: the problem is that upstream is generally not willing to do any OS-specific work, so someone else will have to do the packaging anyway [17:53] ari-tczew: perhaps - on the other way uds is about short-term plans and this is a long-term idea - there has been some discussions about it in Orlando, but the truth is this topis is a complicated one, and there isn't even consensus that this is actually a good idea. [17:53] Bachstelze: for most projects there is no os-specific work other than packaging. [17:55] kklimonda: multiplied by the number of OSes ;) If upstream starts doing Ubuntu-specific work, other distros are going to say "hey you do it for Ubuntu, can you do it for my distro too?" [17:56] because a lot of other distros have even less manpower than we do [17:57] so first the number fo distros must be dramatically reduced, andI don't see it happening [17:57] Bachstelze: I care about Ubuntu and Debian - in my opinion there are too many distributions and it is part of the problem we have. [17:58] I agree, but it's just not going to happen [17:59] it sure would be nice, though, for example with the crapload of linking errors in natty, it would be easier to have upstream fix those than patching everything ourselves [18:00] which is just not going to happen on time, either, there's just too many of them [18:05] well, we can only work on getting Ubuntu that much better, and packaging for Ubuntu that much easier,and distributing software that much "faster" that developer will feel it's a good idea to package for Ubuntu, just as they are doing for OSX or Windows. [18:09] has anyone time to review a project at http://revu.ubuntuwire.com? Here is the link if anyone wants :) --> http://revu.ubuntuwire.com/p/wallch [18:12] an interesting thig to explore would be: for every open source project, there has to be at least one user (or, even better, an upsteam dev) who is also an avid Ubuntu user, and therefore more likely to do the packaging work for that particular project [18:13] maybe a lot of people thik "yes, it would be cool to work on packaging that project I like for Ubuntu, but the package is alreeady there, so I guess they don't need me" [18:16] well, that would be perfect [18:19] brb dinner [18:22] Wallch_Developer: you and your supporters don't need to spam [18:22] we don't spam, just we need a review :P [18:23] Wallch_Developer: I understand but you doing it too visibly. [18:23] I'm looking right now at wallch. [18:23] There are too much concerns. [18:23] yes because now that is christmas we have free time [18:24] ari-tczew: :-/ [18:24] ari-tczew: what are the concerns? [18:24] Wallch_Developer: I'll comment on revu in ~5 minutes. [18:25] nice..! Thanks men :) [18:25] s/men/man [18:26] yeah right.. Thanks man 8-) [18:29] Wallch_Developer: commented. [18:54] ari-tczew: Thx for the comments :) I have 2 questions: 1) Would be nice if upstream have a look on them. http://paste.ubuntu.com/548314/ ->What exactly should I make? You had no error messages at all, only warnings, mainly coming from ignoring results of C functions :) 2) Would be nice if you could send source to Bazaar only for REVU. It’s easier for reviewers to control your improvements. -> I don't get it :D [18:55] /win 10 [18:55] hakermania: well, when I was trying to get clementine I was using Bazaar. Look at https://code.launchpad.net/~ari-tczew/clementine/REVU [18:56] kklimonda: so basically we need to reach out to all those potential maintainers, even if they work on only one package, that's one less package for the rest of us to work on [18:57] hakermania: how create a branch you will find on https://wiki.ubuntu.com/DistributedDevelopment/Documentation/NewUpstream [18:57] hakermania: warnings are just as bad as error, the thought that they aren't is a plague [18:57] s/error/errors/ [18:58] Bachstelze: If you make a program like: [18:58] #include [18:58] system("echo Hello"); [18:58] IMO everything should be compiled -pedantic -Wall -Werror [18:58] you will get error: Warning: Ignoring return value of system() [18:58] is this logical? [18:59] yes [18:59] Bachstelze: No, it isn;t actually :/ [18:59] yes it is [18:59] you shouldn't use system() for that [18:59] or at all, for that matter [19:00] hakermania: in general, it's hard to find these warnings during build, so I pointed to fix it upstream. guess that Wallch_Developer should has a look [19:01] Bachstelze: no, we just have to make it so easy packagefor Ubuntu, and make Ubuntu so popular, that developers are going to package it themselves because this way they can reach enough new users. [19:05] kklimonda: but their software is packaged already, why would they do it themselves? we need people with a strong desire to work for Ubuntu, not just reach new users [19:06] kklimonda: or we just stop packaging stuff and tell upstream "if you want it in Ubuntu, package it yourself"? [19:06] * micahg doesn't think upstreams should have to deal with distro specific stuff [19:07] Bachstelze: but there should be very little work on Ubuntu, or rather it should be focused on so called platform. There are more and more new foss projects, getting people interested in maintaining work on Ubuntu will only get harder. [19:07] micahg: they already deal with Windows and OSX [19:07] kklimonda: yes, because neither has a decent way to distribute packages, a lot of upstreams also make binaries for Linux [19:08] Bachstelze: yes - in my opinion we should create a system that is easy enough to deploy for that they can do it themselves. [19:09] micahg: both will have software stores soon. but my point is that developers are capable of doing os-specific work if the target audience is big enough. [19:10] kklimonda: I think we'd rather have them focus on their area of expertise than ours [19:10] kklimonda: for example, I think it's more worthwhile for them to fix bugs submitted by our users than to maintain packaging [19:11] micahg: packaging really should be as easy as clicking one button, and another to release it on software-center [19:13] ari-tczew: Both have spent equal effort on this app :P :) So, we are both developers of it, but I want to show a more complicated personality (hahahaha) and so I dind't name myself as Wallch_Developer_No_1 [19:14] kklimonda: not going to happen, packaging is just way too complex [19:15] Bachstelze: it'sactually really easy for vast majority of software. [19:15] kklimonda: i agree with you :P Just for the packaging.. ( if it could happen ) .. [19:16] kklimonda: look at all the FTBFSs in Natty, some, maybe most, are on really simple packages (e.g. wvdial) [19:17] a lot of bad things can happen, and then what are you going to do when upstream will say 'I clicked your button, it gave me an error, fix it" [19:17] Bachstelze: it wouldn't be a problem if software updates were separated from os updates. [19:18] kklimonda: this would also require the upstreams to be familiar with the distro processes (SRU, security updates, freezes) [19:18] kklimonda: define "OS"? A BSD-style "base system" separate from third-party software? That would only delay such problems, not eliminate them [19:19] micahg: there would be no such processes - developers would update their software and their pace, in a way they find is the most fitting for their softwate. [19:19] the software would still run, but next time you try to compile it, kaboom [19:19] kklimonda: that won't work for Debian or Ubuntu, maybe arch [19:20] micahg: but maybe it's a good idea to ask ourselves "what would work best for users and developers?" - Ubuntu is not a goal by itself. [19:20] kklimonda: that only works in the Windows/OS X world, not a distro [19:20] kklimonda: stability is key for a lot of users [19:21] it's just a mean to get software from developers to uses. [19:22] micahg: and they would have a very stable system. right now a lot of users are left with broken system every 6 months. [19:22] their other option is to stick with LTS and outdated (in term of features) software [19:23] micahg: I'm just wondering if we are still aiming at being a software distribution, or the os built on foss [19:23] ari-tczew: I need help on making a branch. The link you sent me really confused me. I've seen something from launchpad about 'branch'. So, what do I do here: http://i53.tinypic.com/14munhj.jpg ? [19:24] Bachstelze: most ftbfs in natty could be easily fixed by upstream devs, their usets would't be aware of this problem. [19:24] hakermania: you're not importing, you just creating [19:24] kklimonda: true, but the fact is that the problams are there now, it's pointless to say "it's upstream's fault", even if it's true [19:25] Bachstelze: I'm not really saying that. [19:25] hakermania: I'll quote you commands [19:25] hakermania: get into source package [19:26] hakermania: cd wallch-1.0 [19:27] hakermania: bzr init-repo wallch/revu [19:27] Bachstelze: the ftbfs we get are something that they will have to fix anyway, if we were just delivering platform for them they would be able to fix their own mistakes (with our passive help) [19:27] sorry, wrong [19:28] hakermania: another: 1st bzr init-repo wallch/revu [19:28] hakermania: then go to revu directory and copy there all your sources from wallch-1.0 [19:29] kklimonda: I fail to see how that would make any difference, in both cases they will fix them when they see fit, and with equivalent amounts of work [19:29] kklimonda: but I agree that some parts of the system (e.g. the build toolchain) are moving too fast [19:30] expecially since they aren't really relevant to anyone [19:30] Bachstelze: actually, most of us are not familiar with code we are"maintaining" so our fixes for various bugs are suboptimal. It duplicates work. [19:30] certainly not tu users, and not to developers either, since new software builds just as fine with gcc 4.2 or 4.3 than with gcc 4.5 [19:31] Bachstelze: if software updates were left to developers and separated from os updates we would get a much more stable os - the question is how much less stable would software become. [19:32] that's where I think a BSD-style "base system vs. third party software" would be good in Ubuntu, even if we were to maintain both parts, we could do so at different speeds [19:32] ari-tczew: 'bzr init-repo wallch/revu' : bzr: ERROR: No such file: u'/home/alex/Desktop/ALL/REAL70/wallch-1.0/wallch/revu/': [Errno 2] No such file or directory: '/home/alex/Desktop/ALL/REAL70/wallch-1.0/wallch/revu/' [19:32] e.g. the "base system" would change only at LTS releases [19:33] i kinda like that idea [19:34] hakermania: do it in REAL70 directory [19:36] ari-tczew: Cool : Shared repository with trees (format: 2a) Location: shared repository: wallch-1.0/revu Now? [19:38] hakermania: You didn't see my sentences: [20:28] hakermania: another: 1st bzr init-repo wallch/revu [20:28] hakermania: then go to revu directory and copy there all your sources from wallch-1.0 [19:39] ari-tczew: I did, "another 1st bzr init-repo wallch/revu" ????? "go to revu directory and COPY" ???? I cannot understand. :( [19:40] omg [19:40] !omg | ari-tczew [19:40] ari-tczew: Please don't use "LOL" and "OMG" and so forth on a regular basis. This is IRC, not IM, and using those lines on their own is not required, and it is rather annoying to the rest of the people in the channel; thanks. [19:41] kklimonda: I don't care [19:41] ari-tczew: Sorry for the inconvenience :( [19:42] hakermania: don't be in wallch-1.0 directory [19:42] I was wrong [19:42] ari-tczew: Yes, the command 'bzr init-repo wallch-1.0/revu' worked!!! After this? [19:43] ari-tczew: you don't care that it's annoying? There are almost 200 other people here and quite a lot of them do care so please, care about it too. It's not enough to betechnically profficient, yougeneral attitude is also important. [19:43] hakermania: bzr init-repo wallch/revu [19:44] kklimonda: ban me then [19:46] ari-tczew: it's not an argument [19:47] kklimonda: I can use my time more useful than pointless discussions. [19:50] ari-tczew: Listen, the command worked and created /home/alex/Desktop/ALL/REAL70/wallch-1.0/revu/.bzr which contains branch-format branch-lock/ README repository/ [19:50] ari-tczew: it's not pointelss, your attitude was the main counter argument in you motu process, I'd rather see you work on it now that you are motu than ignore the problem. [19:52] kklimonda: My fix for this problem is following: to all folks who have concerns to me: improve your social life [19:53] hakermania: I told you wallch/revu not wallch-1.0/revu [19:54] ari-tczew: I know, but wallch/revu nowhere works. (Inside or outside the source folder) [19:55] hakermania: it should be outside of the source [19:56] ari-tczew: No, I get no such file error :/ http://paste.ubuntu.com/548334/ [19:57] ari-tczew: Speaking as someone who has had to soften his tone, please try to remember that we try to be inclusive, and attitude counts a great deal. [19:58] crimsun: could you tell more about first part of your sentence? [19:59] crimsun: could you sponsor something for me @main? [19:59] ari-tczew: I've become less abrupt over the past several years. [20:00] Guys, please....? [20:00] hakermania: be patient [20:01] No, I don't mean that i need an answer, i mean that I think the issue about your attitude should be over. [20:01] hakermania: agreed [20:01] crimsun: nice to hear that there is no only stiff people [20:05] hakermania: try: bzr init-repo revu [20:05] hakermania: then copy all files from wallch-1.0 to revu [20:10] ari-tczew: Thank you, a revu/ directory was created beside the wallch-1.0 directory. How exactly will i 'copy' the files form wallch-1.0/ to REVU? I only know about 'dputting' to REVU (dput -f *changes etc) [20:10] hakermania: locally you have just directory [20:11] ari-tczew: Oh, now I get you ;) [20:11] yeeaahhhh bingo [20:12] ari-tczew: your comments just make it clear that there is some problem with your attitude, ignoring it won't make it disappear. We can do that though, t's not my place to to teach you how to behave. [20:12] crimsun: have you got time? [20:12] ari-tczew: Haha :P Think that I was ready to ask you what command to use :P Ok, done, wallch-1.0/* has gone to revu/ :) What's next? [20:13] kklimonda: let associate with micahg and try to get out me from there [20:14] I'm pretty sure that it will be benefit for development. [20:14] hakermania: try bzr commit [20:14] (in revu directory) [20:14] ari-tczew: in 15 minutes, yes [20:15] crimsun: I'd like to bse sponsored by you [20:15] is it possible? [20:15] ari-tczew: please check then; I'll have time to look [20:16] crimsun: can I subscribe you to bug? [20:17]