| wgrant | slangasek: Timeouts with an OOPS ID? Or timeouts with a "Sorry, we couldn't connect to the Launchpad server" sort of thing? | 00:22 |
|---|---|---|
| slangasek | wgrant: "couldn't connect" | 00:22 |
| wgrant | Ew. | 00:22 |
| wgrant | Had a report of that last night, also while filing a kernel bug. | 00:23 |
| wgrant | Interesting. | 00:23 |
| fagan | I get that a lot on the edge server | 00:23 |
| slangasek | I gather that the kernel's apport bits are now quite large :) | 00:23 |
| fagan | if you keep trying you get it eventually | 00:23 |
| wgrant | slangasek: Do you recall how big it was in this case? | 00:24 |
| fagan | the edge sever has a much lower time out than the main server | 00:24 |
| slangasek | wgrant: hum, I don't know anywhere that it would've said | 00:24 |
| wgrant | slangasek: Doesn't apport normally say before it sends? | 00:25 |
| slangasek | I don't know :) | 00:25 |
| wgrant | Heh. | 00:25 |
| slangasek | maybe! I didn't look | 00:25 |
| wgrant | fagan: This is far nastier than a normal timeout, I'm afraid. | 00:25 |
| slangasek | I didn't hit the error until after it had sent | 00:25 |
| slangasek | the timeout I was getting was after the data had been uploaded, and I was trying to submit the bug /submission/ | 00:25 |
| fagan | Oh couldnt connect is a strange one | 00:25 |
| penguin42 | wgrant: Sounds like what I was reporting earlier and last night ? | 00:26 |
| wgrant | penguin42: Exactly. | 00:26 |
| wgrant | slangasek: Oh, that's even worse. | 00:26 |
| wgrant | Yay. | 00:26 |
| fagan | did anyone ask on #launchpad? | 00:26 |
| wgrant | Yes, that's why I'm here. | 00:26 |
| wgrant | Because slangasek ran away. | 00:26 |
| slangasek | fagan: I did, but then I retracted because the next attempt to post went through :) | 00:26 |
| fagan | oh | 00:26 |
| slangasek | bug #635379, fwiw | 00:26 |
| ubottu | Launchpad bug 635379 in linux (Ubuntu) "intel i945 GPU lockup, requires reboot to restore X" [Undecided,New] https://launchpad.net/bugs/635379 | 00:26 |
| slangasek | but before that, it was persistent for ~30min or so | 00:27 |
| wgrant | This may be bad firewall rules again. | 00:27 |
| === _b_j_f is now known as bjf[afk] | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === rgreening_ is now known as rgreening | ||
| atari2600a | hey | 06:19 |
| atari2600a | empathy is accidentally my entire config upon restart | 06:20 |
| atari2600a | more specifically my accounts | 06:20 |
| atari2600a | any workaround until the package gets fixed? | 06:20 |
| dylan-m | atari2600a: I think you accidentallied a verb, but I'd guess the likeliest place to ask that question is #ubuntu+1 (the discussion / support / trying to use the thing channel for 10.10) | 06:36 |
| atari2600a | thanks dylan | 06:43 |
| cjwatson | just so people know: bugs aren't being auto-closed by uploads right now, so you have to close them manually. A Launchpad fix is on its way | 09:26 |
| cjwatson | bug 634045 | 09:26 |
| ubottu | Launchpad bug 634045 in Soyuz "Regression: Launchpad-Bugs-Fixed header no longer works" [High,Triaged] https://launchpad.net/bugs/634045 | 09:26 |
| gellmar | hi! Are here any maintainers for UDFtools? | 09:44 |
| roxdragon | ih | 13:51 |
| Pretto | where do i find information about hal not installed by default and what is used in it's place? | 14:41 |
| fagan | Pretto: hal was replaced by a few things really | 14:44 |
| fagan | read the top note here to get the list http://freedesktop.org/wiki/Software/hal | 14:46 |
| Pretto | fagan: thank you | 14:47 |
| fagan | np | 14:47 |
| Damascene | hi, | 14:56 |
| Damascene | I wish you release ubuntu less often. It's hard to follow all these releases for paid persons rather than volunteers | 14:56 |
| Damascene | too much regression | 14:57 |
| === JFo is now known as JeremyFoshee | ||
| === JeremyFoshee is now known as JFo | ||
| G | Damascene: the LTS releases are designed for people that need stability and long term support (LTS) | 15:05 |
| ari-tczew | Damascene: if you want to give an idea about longer development cycle, let's use listmails discussion or use brainstorm. | 15:06 |
| ari-tczew | btw. I also think that development cycle should be longer. | 15:06 |
| Damascene | ok, thanks both | 15:07 |
| G | rapid releases have kinda put me off a little too, so often features look unpolished | 15:10 |
| G | (in my eyes) | 15:10 |
| G | but not just Ubuntu | 15:10 |
| Damascene | and any way every one can get the latest version from some launchpad ppa | 15:19 |
| directhex | Damascene, that only works for leaf packages. personally, i like the short release cycles, as it encourages setting and reaching goals | 16:02 |
| Damascene | you might be right. but the current release system is too short I think | 16:03 |
| Damascene | you know the default for many people is to update when there is new release and that might case many problems for them | 16:04 |
| directhex | Damascene, if people want long-term supported releases, use long-term supported releases (6.06, 8.04, 10.04) | 16:04 |
| Damascene | well as a user we just call it old release :) | 16:05 |
| Damascene | any way I'm thinking of creating a wiki page to start a discussion about that | 16:06 |
| directhex | the mailing list is the correct arena for this | 16:07 |
| ChogyDan | Damascene: it is probably better to focus on specific packages then the release as a whole. Projects should follow their own release schedule, no? | 16:07 |
| directhex | although people will just say the same thing - use LTS if you want long-term support | 16:07 |
| Damascene | ChogyDan, many developers and users complain about not having the last version in the release. why not let them do it in their ppa and blame it on them. | 16:09 |
| Damascene | the first thing they say when you try to report but is to use the last version they have. not Ubuntu's one. | 16:10 |
| ChogyDan | Damascene: that sounds like an argument for shorter releases, I don't think I follow | 16:11 |
| Damascene | no what I mean is to let the developers to handle the software release and Ubuntu to handle the core. and release less often. | 16:12 |
| Damascene | brb | 16:12 |
| directhex | i think mdz argued for the latter part | 16:14 |
| directhex | problem is upstreams are awful at distro integration | 16:14 |
| directhex | and, again, it can only work for leaf packages | 16:14 |
| Chipzz | Damascene: IMO, you can't have your cake AND eat it | 16:32 |
| Chipzz | which means: either you choose stability, ie LTS, or you choose in between releases, with the possibility of regeressions | 16:32 |
| Damascene | why not using decentralized Ubuntu? developers control their own apps releasing | 16:33 |
| Damascene | then the problems is not ubuntu's problem | 16:34 |
| === yofel_ is now known as yofel | ||
| Damascene | directhex, if developers don't want their programs to be in the most popular open source OS it would be awkward | 16:36 |
| ogra_cmpc | Damascene, i think yous problem is your view here ... you see apps and core bit totally ignore integration which is the main part ubuntu devs are doing ... ubuntu featurs usually consist of a combination of a bunch of apps with added glue inbetween | 16:38 |
| ogra_cmpc | if you let one app move forward independently the feature can break ... you cant guarantee even a minimal level of QA etc | 16:38 |
| Damascene | why don't we start with an another repo like universe where developers can just push their apps there and see the outcome? it would be optional and for testing. when I had to install the latest evolution I just had to add it's ppa. it seems simple to have a universal open to developers ppa | 16:43 |
| Chipzz | also, with a decentralized approach you also loose all Q&A | 16:44 |
| Chipzz | same problem | 16:44 |
| Chipzz | Damascene: you ignore the gist of the problem, really | 16:44 |
| Chipzz | I think you lack a basic understanding of what is really the issue here | 16:44 |
| Chipzz | which is a lack of manhours | 16:44 |
| Chipzz | and he necessity for Q&A | 16:44 |
| Damascene | Chipzz, so in the current state Ubuntu is doing QA of other apps? | 16:44 |
| Chipzz | they're doing at least some form of Q&A on the packages, not necessarily the apps | 16:45 |
| Damascene | why do you thing the developers can not do that if you linked them directly with the users? | 16:45 |
| Chipzz | like I already told you, lack of manpower | 16:46 |
| ogra_cmpc | the scenario you describe above already exists, we call it launchpad :) | 16:47 |
| ogra_cmpc | every upstream dev is free to add his/her project and provide daily builds, stable builds etc in a ppa | 16:47 |
| ogra_cmpc | why would you want to make all of universe unstable if single people only need single apps | 16:48 |
| Damascene | ogra_cmpc, but that should be done by manual for every package | 16:48 |
| ogra_cmpc | it is already happening for some | 16:49 |
| tumbleweed | Damascene: it has to be manual. Every package is different | 16:49 |
| Damascene | the idea for now is to have another repo for now with the latest release from developers | 16:49 |
| ogra_cmpc | but be sure ubuntu as a distro wont give up its stability for a permanently rolling archive | 16:49 |
| ogra_cmpc | Damascene, https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted | 16:52 |
| Damascene | what I see now look like this. developer release package version 1 stable and 1.5 in testing. ubuntu has the package version 0.5 stable and 1.0 in testing. ubuntu users are using 0.5 and find bugs while there is 1.5 going to be released | 16:52 |
| ogra_cmpc | its not a matter of ubuntu but a matter of devs making use of the reciepoes for daily builds | 16:52 |
| ogra_cmpc | *reciepes | 16:52 |
| Damascene | ogra, developers are not releasing daily! they have stable and testing too. | 16:53 |
| ogra_cmpc | up to them | 16:53 |
| * ogra_cmpc only releases stable | 16:53 | |
| ogra_cmpc | everything else is development ;) | 16:53 |
| Damascene | I just hoped to find something to release the gap | 16:53 |
| ogra_cmpc | see the help page above | 16:54 |
| ogra_cmpc | its supposed to close the gap | 16:54 |
| Damascene | * lower the gap | 16:54 |
| Damascene | yes the word is close | 16:54 |
| Damascene | :) | 16:54 |
| ogra_cmpc | but it needs adoption on the developer side | 16:54 |
| ogra_cmpc | which you wont get from many sides due to political reasons | 16:54 |
| ogra_cmpc | which is alo not a job for ubuntu to solve | 16:55 |
| ogra_cmpc | *also | 16:55 |
| Damascene | let me gather my ideas and start a wiki page. things need to be sorted in some place. | 16:56 |
| Chipzz | Damascene: look, it's very simple; 0.5 gets released with the LTS, and 1.0 gets released by upstream after. It's simply not desirable to move 1.0 to the LTS, because the problems with 0.5 are known and documented. If you were to push 1.0 to LTS for every single piece of software, your LTS would hardly be stable | 16:57 |
| penguin42 | that's what backports for isn't it? | 16:57 |
| Chipzz | penguin42: not exactly, no | 16:58 |
| penguin42 | Chipzz: But partially, yes ? | 16:58 |
| Damascene | :) | 16:58 |
| Chipzz | penguin42: if you're going to push every 1.0 release into backports, you might just as well run a non-LTS release, or even a development release | 16:58 |
| Chipzz | and exactly what have you gained then? | 16:58 |
| ogra_cmpc | more workload :) | 16:59 |
| Chipzz | :) | 16:59 |
| Chipzz | and from the user POV, you have gained little to nothing | 16:59 |
| penguin42 | Chipzz: Yeh but it helps for the few packages which get a really major useful upgrade | 16:59 |
| ogra_cmpc | which in turn boils down to the "lack of manhours" from above | 16:59 |
| tumbleweed | penguin42: all packages get really useful upgrades, but they also get new bugs | 17:00 |
| Chipzz | penguin42: if you put package a into backports, another user is going to whine to get package b in too, and another package c, ... | 17:00 |
| Chipzz | I think this discussion is pointless and silly | 17:01 |
| Chipzz | Damascene fails to understand what a release is, and fails to appreciate the amount of work it takes | 17:01 |
| Chipzz | and the discussion is going around in circles | 17:01 |
| Damascene | Chipzz, developers releasing with bugs is because of the lack of user testing | 17:01 |
| Damascene | thanks for the nice discussion. | 17:02 |
| Chipzz | Damascene: like I said before, your POV is basically "I want more updates" and the answer to that is basically "Can't do due to a lack of manpower" | 17:03 |
| Chipzz | and this isn't going to get fixed unless canonical hires more ppl | 17:03 |
| penguin42 | how much automated testing happens? | 17:03 |
| Damascene | not exactly. the update are their but needs some of Ubuntu man power for testing instead of providing packages that the upstream do not want to support | 17:05 |
| Damascene | * there | 17:05 |
| Damascene | I know this is not Ubuntu only problem and it can not solve it alone. developers will have to make sure there packages are really stable | 17:06 |
| ogra_cmpc | Chipzz, why would it be a matter of canonical hiring anone ? | 17:08 |
| ogra_cmpc | its a matter of having more devs, no matter if they are employed by canonical, TI, dell, or are hobbyists | 17:10 |
| Chipzz | ogra_cmpc: right; but that would be the easiest solution | 17:10 |
| Chipzz | ogra_cmpc: the quality of packages hardly is garantueed when a package is made by a volunteer | 17:11 |
| * ogra_cmpc disagrees | 17:11 | |
| ogra_cmpc | a volunteer often is more intrested in his package than someone being paid for maintining other peoples software imho | 17:12 |
| tumbleweed | Chipzz: where does debian's legendary stability come from then? | 17:12 |
| Chipzz | ogra_cmpc: do I really need to point out the (perceived) lack of quality of a lot of packages in universe/multiverse? | 17:14 |
| Chipzz | tumbleweed: do you really want an answer to that? | 17:14 |
| mr_pouit | yes… | 17:14 |
| tumbleweed | Chipzz: I'd say that's because there aren't enough people for the size of universe | 17:14 |
| ogra_cmpc | Chipzz, do i need to point ut the overworkedness of many paid canonical devs ? | 17:15 |
| Chipzz | IMO the better quality of packages in debian is because of the New Maintainer process, which assures people are intimately familiar with the debian policy because they get asked questions about it during the course of the NM process | 17:15 |
| Chipzz | ogra_cmpc: I am not pointing a finger at Canonical Employees here | 17:16 |
| Chipzz | what I *am* saying is that the barrier to becoming a MOTU is much lower, resulting in underqualified MOTU's | 17:16 |
| Chipzz | not all of them, mind you | 17:17 |
| ogra_cmpc | well, you are assuming canoinical hiring more employess would help in any way | 17:17 |
| tumbleweed | probably true. But also not enough of them. I see more neglected packages than packages where MOTUs screwed up | 17:17 |
| ogra_cmpc | canonical is a company working for revenue ... | 17:17 |
| ogra_cmpc | adding more people requires to make more of it | 17:17 |
| ogra_cmpc | the only solution can be to get more voluteers | 17:18 |
| Chipzz | ogra_cmpc: it would help the quality of packages, since Canonical would presumably only hire very qualified ppl | 17:18 |
| directhex | canonical employees are not better by definition than community MOTU | 17:18 |
| ogra_cmpc | no matter if for main or universe | 17:18 |
| directhex | IME, anyway | 17:18 |
| Chipzz | directhex: I would hope they are, or Canonical has a serious problem screening new hirees | 17:18 |
| ogra_cmpc | Chipzz, it wouldnt ... | 17:18 |
| directhex | Chipzz, again, my experience says otherwise. | 17:19 |
| directhex | the biggest problem with universe is that people upload to it | 17:20 |
| ogra_cmpc | canonical hires the best for the task if it can ... but people plainly tasked with only packaging are very very rare in the company | 17:20 |
| penguin42 | I guess it depends; some community guys are full time experienced programmers anyway - they just don't happen to work for canonical | 17:20 |
| directhex | universe quality is at its worst when people upload stuff directly which isn't in debian, then never maintain it long term | 17:21 |
| === emma_ is now known as emma | ||
| directhex | second worse is when they introduce an ubuntu delta from debian, then never notice that it needs an update (but there is more chance of it being noticed than when the upload is ubuntu only) | 17:21 |
| ogra_cmpc | directhex, that applies to main as well | 17:22 |
| directhex | third worst is when ubuntu distro changes mean a direct unmodified debian package doesn't work, even though the package itself is unmodified | 17:22 |
| directhex | ogra_cmpc, yeah, but at least people are meant to care more about main. i try not to abuse my upload powers | 17:22 |
| Damascene | https://wiki.ubuntu.com/damascene/Decentralized%20Ubuntu | 17:45 |
| Damascene | I made that page for the subject | 17:45 |
| === bjf is now known as bjf[afk] | ||
| === dendro-afk is now known as dendrobates | ||
| === almaisan-away is now known as al-maisan | ||
| === apparle_ is now known as apparle | ||
| ScottK | Chipzz: The perceived lack of quality for Universe/Multiverse is due to lack of manpower and packages being left unmaintained. It is (almost always) not because someone is working on the packages and doing it badly. | 20:53 |
| ScottK | Also getting hired by Canonical doesn't give anyone upload rights. MOTU/Core-dev that are employed by Canonical get approved the same way community people do. | 20:55 |
| === tester_ is now known as ia | ||
| === al-maisan is now known as almaisan-away | ||
| === Amaranth_ is now known as Amaranth | ||
| Chipzz | ScottK: like I pointed out before, my comment wrt Canonical hiring ppl should be interpreted in terms of Canonical having lots of knowledgable ppl, which will be the ones reviewing applications, and as a result them hiring only knowledgable ppl | 23:55 |
| Chipzz | as opposed to ppl in MOTU who may be rather new to packaging | 23:55 |
| Chipzz | I was in no way implying that Canonical employees get a different treatment due to being employed by Canonical, but rather that it stands to reason that Canonical employees deliver high-quality work | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!