Re: systemd-shim [Re: How to avoid stealth installation of systemd?]
On Tue, Jul 1, 2014 at 9:59 PM, Tollef Fog Heen wrote: > ]] Michael Biebl > >> Am 01.07.2014 19:53, schrieb Steve Langasek: >> > new init. But the systemd maintainers are anxious to update to a newer >> > version in unstable, and while there are plans in Ubuntu to make >> > systemd-shim support the interfaces needed for newer logind, this isn't >> > ready yet. >> >> This issue has been known since December 2013 and was also discussed >> during the ctte debate. >> >> Tollef back then promised to hold back any updates until May 2014. >> We are way past that date. > > Just as a heads-up: We're planning on making 208 hit unstable once 204-9 > is in testing, and then follow up with newer versions once we deem they > are ready. > > Cc-ed to systemd-shim@packages so those maintainers are explicitly > aware. Do you mean 204-14? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caa77j2dvkyrtdglt9rez4-uobefrgvynfzs9jcnotcaegff...@mail.gmail.com
Re: Future of Developer's Reference
On Thu, Jun 19, 2014 at 3:05 AM, Clint Adams wrote: > On Wed, Jun 18, 2014 at 02:08:59PM +0200, Jakub Wilk wrote: >> Somewhere in another universe, someone proposed moving Developer's >> Reference to the wiki. One of the arguments was that it would let >> you make changes _quickly_. I'm shamelessly :-P disclosing a message >> in this thread: > > Since the entire history of the Developer's Reference has been rife > with bullshit, that would seem like a feature. Does 'bullshit' mean that the content is of low quality, or are there other issues? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAA77j2Ad=PAiM7Yf=7xr99rkbycturqusrsskukl+ponfte...@mail.gmail.com
Re: Bits from the systemd + GNOME sprint
On Sun, May 4, 2014 at 12:55 AM, Matthias Urlichs wrote: > Hi, > >> > 212 was released in March. Why not package that? >> > Not having been there, I would guess that packaging 208 had already begun > before the sprint, and thus should be completed and reasonably bug-free > before going forward to yet another version with (probably) its own issues. That was my guess, but I didn't want to speculate, just in case there are issues with later versions, for example. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caa77j2awzdoysdljhybjn5uueufiezsekccbshbsquw...@mail.gmail.com
Re: Bits from the systemd + GNOME sprint
On Fri, May 2, 2014 at 1:26 AM, Jordi Mallach wrote: > Michael B. also updated systemd to 208 in experimental. 212 was released in March. Why not package that? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAA77j2AXyn=2d05wall4eimalky_5y7utilft6gfkcatevr...@mail.gmail.com
Re: Automatic removal of packages from testing
On Mon, Sep 30, 2013 at 5:13 PM, Joey Hess wrote: > Niels Thykier wrote: >> [KEY-PACKAGES] >> http://udd.debian.org/cgi-bin/key_packages.yaml.cgi > > If you're curious, as I was, how this list is arrived at, here's the > source: > > http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=scripts/update-key-packages;h=d214dcbbe4aea5b2b49b132a0c135dfef40cf71f;hb=6743df0478511a99f4d779db8229a92a0d938da3 > > Basically, 5% of popcon submitters have it installed, or it's part of > debian-installer, or something debian-cd includes on CDs (including > task packages). Thanks for the link; I was also curious, but a quick search didn't help. I just assumed it was discussed on debian-release, which I don't read. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caa77j2d12symo6vaky79cet22bkhtpma45olojmcm2y+oz1...@mail.gmail.com
Re: Bug#638720: ITP: openerp6-server -- Enterprise Resource Management (server)
On Mon, 2011-08-22 at 16:33 +0200, Florian Reitmeir wrote: > Hi, > > W. Martin Borgert wrote: > > Quoting "Charles Plessy" : > >> I think that it would help to understand that the package contains if the > >> acronyms ERP, CRM, POS were expanded (and maybe also GUI and *-RPC). > > > > I thought exactly the same when sending the bug :~) Will do! > > Is there now an upgrade path for all the OpenERP v5 users in Debian? > Is there an upgrade tool planned for the version 7? > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619576 > > I have an openerp with a lot of data in it (version 5), and the company > (=OpenERP) states, i need to purchase their "upgrade tool" to transfer > my data to version 6. Using the backup tool from the web UI and restoring it doesn't work? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314082786.4256.1.camel@tshepang.tauspace.local
Re: Bug#632450: ITP: pmatch -- Duplicate finder and removal tool.
On Sun, 2011-07-03 at 08:35 +0200, Thomas Koch wrote: > I don't think we need another tool for this. Maybe it's better than them in some way (not necessarily overall), which in my books would make it good enough, meaning *we need another tool for this*. > And I don't think such basic tools should be written in a scripting > language. If this isn't a joke, it's a real bad reason. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1309744356.25604.21.camel@debian
Re: Bug#632450: ITP: pmatch -- Duplicate finder and removal tool.
On Sun, 2011-07-03 at 13:02 +0200, Thomas Koch wrote: > Ok, I didn't see that this ITP already had a discussion. However there are > three minor and subjective issues that I have with this ITP: > > - It's not really in the spirit of Open Source of Free Software to start a > new > project, if there already are a douzen projects in the same area. If none of > them fits your needs perfectly there should be at least one that could be > extended to your needs instead of starting from scratch. Many tools (perhaps most FLOSS) start off as toy projects, with the author not expecting to go far with them. And then they get to the point where they actually start being useful, even being better than existing ones. In such a case, you don't really want it thrown away or kept private right? Imagine that there isn't much motivation (e.g. wrong language, ugly code, not enough time, too boring) to port back the features to the older tool. > - It's always better if somebody else beside the upstream author who also > wants a package to be in Debian. In that case there's proof that the package > is at least important for a second person. What of cases where the package would get wider usage simply for being available in Debian? I'm not saying all trash should be accepted, I'm just saying that if, for example, one's own project is their first real exposure to technical Debian work, why not have them start with what they want the most for now... package their project for Debian? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1309743962.25604.15.camel@debian
Re: distinguish between "core" and "main"?
On Sun, 2011-06-05 at 18:02 +0200, Harald Dunkel wrote: > I cannot speak for others, but I don't wait 3 years. I do > regular updates/upgrades to include the most recent security > and bug fixes. We've scheduled regular maintenance weekends > every 3 months for this. Important updates are installed > immediately. NOTE: I specifically chose the words "system upgrade", so as to be clear I'm not including security updates and stability fixes. So, you want Debian to change its release management to suit you, while neglecting what is likely its largest userbase. I'm here referring to users who don't want to do system upgrades every 3 months. > >> Of course this doesn't make the +29000 packages outside of the > >> proposed core repository go away. But I think we already agreed to > >> use testing for installations of "non-core" packages. > > > > But it makes them second-class. > > They are surely not second-class, they are just not within core/stable. > Debian already classifies packages in different priorities, to > be used today when package updates are pushed into testing, for > example. I just cannot use these priorities in sources.list, _and_ I > cannot rely upon the packages in today's testing to work with the > core packages in stable Hmmm... > > Also, backports is supposed to fix this > > anyway. All needed there is volunteers willing to do the work. Why would > > you want a different scheme? > > > > Because backports is not supported as good as the current > testing repo. Why have a 3rd repository next to stable and > testing with a similar package set, instead of keeping an > eye upon compatibility right from the start? What do you mean by "backports is not supported as good as the current testing repo"? Do you mean the packages there are too small in number? Talking about your proposed scheme, let's assume that the GNU toolchain would be part of core/stable. Would you agree that keeping it compatible with the rest of the system means building the rest of the system with it? That means keeping it hostage and not updating it for a set period of time. Now what backports does is that you'll use build tools in stable to build newer software than is available in stable, to avoid upgrading a "certified stable" base. And this is a compromise between stability and freshness. If I'm accurate thus far, it means you are asking for making a backports system the main way of doing Debian, and neglecting about everyone else. I'm saying this because we can't have a main/testing system that's built both by a core/stable version of this toolchain and a main/testing version. Am I missing anything (sorry if I'm making you repeat yourself)? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1307296843.19746.31.camel@debian
Re: distinguish between "core" and "main"?
On Sun, 2011-06-05 at 08:29 +0200, Harald Dunkel wrote: > Hi Neil, > > On 06/04/11 19:01, Neil Williams wrote: > > > > Testing compatibility is the larger problem. Automated tests can only > > go so far. Dependencies are one thing, bugs which arise because one > > setup is using a version which has already been replaced in testing. > > > > As a consumer I would like to get a system that keeps up to date > (as today's testing does), but with a stable core package set. I > would like to install the most recent stable core system, and use > testing for everything else. > > All these APIs and dynamic libraries are meant to provide backward > compatibility. We also have versioned package names to work around > compatibility problems. But we don't really rely on this, except for > updates within testing or unstable. > > >>> If you sincerely want the Debian system which has had the most testing > >>> of all possible variants and which Debian can honestly describe as "the > >>> most likely candidate for a system where packages work together as > >>> nicely as it is practical to achieve" you MUST use stable and then keep > >>> that up to date with the stable point releases and security updates. > >> > >> The problem with this is Debian's long release cycle (+2 years, as it > >> seems). Its difficult to get help from upstream if the source code in > > > > Then use chroots, as explained in my first message but which you appear > > to have ignored. > > > > Probably I had misunderstood your "Building stuff then takes place in > chroots, e.g. using pbuilder". I had associated pbuilder with "building > packages". > > > I do this every single working day. I run a number of boxes using > > stable - each has pbuilder support for sid and most have pdebuild-cross > > support for cross-building for armel based on stable or unstable. > > > > Instead of pbuilder I am using virtual machines (kvm & vserver) > with testing today. Their biggest advantages (as with pbuilder I > would guess) are hiding the real hardware and keeping things separate > from each other. > > The downside is that everything gets more complex, but not necessarily > more stable. You've got even more systems to run and more packages to > install, not to mention that updates of the virtualization server > are more difficult to do. > > My virtualization servers themselves were running testing, too, but > since Squeeze has been released testing is changing rapidly. Currently > I cannot rely upon testing for server installations. > > > The long release cycle arises from the very thing you appear to cherish > > - the quality and stability of the stable release. It takes time and > > people to generate quality. That's the entire problem - there are not > > enough people to do that testing twice over. > > > > > > Testers = people. There are as many permutations as there are testers - > > or if you really want the figures, work out how many possible > > permutations there are for installing 1,500 packages out of a total > > selection of 31,000. Then find people to test each permutation on a > > daily, regular usage basis - ensuring that each person fully tests > > EVERY application in their particular set. > > > > Understood. If you reduce the number of packages to be released by > focusing on a core package set with 1000 or 1500 packages instead > of +3, then your can do more rapid releases because there are > fewer packages to wait for matching the release criteria. By rapid releases, are you referring to core/stable or main/testing? How rapid? Do you mean people would now do system upgrades in less than 2-3 years (life of a Debian release)? > Of course this doesn't make the +29000 packages outside of the > proposed core repository go away. But I think we already agreed to > use testing for installations of "non-core" packages. But it makes them second-class. Also, backports is supposed to fix this anyway. All needed there is volunteers willing to do the work. Why would you want a different scheme? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1307272657.16407.10.camel@debian
Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?
On Sat, 2011-06-04 at 16:16 -0700, Steve Langasek wrote: > On Sat, Jun 04, 2011 at 11:54:00PM +0200, Tshepang Lekhonkhobe wrote: > > On Sat, 2011-06-04 at 14:10 +0200, Gergely Nagy wrote: > > > (Provided that said action does not cause unwanted side effects, like > > > the documentation being out of date, because upstream forgot to > > > regenerate them before distribution - but that falls under the "upstream > > > to not be a moron" above ;) > > > I see this was some sort of joke, but did you have to call a volunteer > > that made a mistake a moron? Did you have to repeat that negative label > > twice? > > Do you have to make a fuss on a public mailing list every time you don't > like the tone someone uses? I find getting mired in meta discussions about > people's word choice much more damaging to the climate of our mailing lists > than the occasional rude remark. > > :) > And I don't think there was anything inappropriate about Gergely's message, > either. Referring to a *hypothetical* upstream as a moron is whimsical, not > offensive. Perhaps I was being too sensitive there. Sorry for soiling this thread. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1307233699.15003.13.camel@debian
Re: distinguish between "core" and "main"?
On Sat, 2011-06-04 at 08:54 +0200, Harald Dunkel wrote: > On 06/04/11 07:56, Paul Wise wrote: > > Sounds like you are looking for backports.debian.org? > > > > Backports for Squeeze contains just about 400 package, > AFIACS. Would this be good enough for you if there were thousands of packages instead? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1307226818.12430.24.camel@debian
Re: Ok to use upstream doumentation as-is (i.e. not regenerate)?
On Sat, 2011-06-04 at 14:10 +0200, Gergely Nagy wrote: > (Provided that said action does not cause unwanted side effects, like > the documentation being out of date, because upstream forgot to > regenerate them before distribution - but that falls under the "upstream > to not be a moron" above ;) I see this was some sort of joke, but did you have to call a volunteer that made a mistake a moron? Did you have to repeat that negative label twice? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/130722.12430.3.camel@debian
Re: new scripts and patches for devscripts
On Tue, 2011-05-24 at 23:51 +0200, Benjamin Drung wrote: > Am Samstag, den 21.05.2011, 21:41 +0200 schrieb Tshepang Lekhonkhobe: > > On Thu, 2011-03-10 at 00:26 +0100, Benjamin Drung wrote: > > > Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega: > > > > On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung > > > > wrote: > > > > > Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: > > > > >> On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: > > > > >> > Should these script moved from ubuntu-dev-tools into devscripts? > > > > >> > > > > > >> > Most of the script are written in Python. Rewriting them to get > > > > >> > them > > > > >> > included in devscripts is too much work without benefit. devscripts > > > > >> > would depend on python then. > > > > >> > > > > >> Most of the scripts are short. Rewriting would be fairly simple, and > > > > >> may be beneficial in removing the Ubuntu-specific bits. > > > > > > > > > > What speaks against having these script in python? Is python too heavy > > > > > for a _development_ machine? > > > > > > > > It's not just about a package dependency. It's more about restricting > > > > the knowledge base required for those maintaining the package. > > > > > > > > Considering that scripts are contributed to devscripts and the support > > > > burden is then commonly left on the shoulders of those maintaining > > > > devscripts instead of the original script author, it's in our interest > > > > to maintain a consistent set of languages that we are willing to > > > > support. This is currently Perl and shell. > > > > > > > > So yes, IMO, accepting scripts written in Python (or any other language) > > > > is too heavy. Not for a "_development_ machine", but for a maintenance > > > > team. If people choose to ignore our requirement and develop scripts in > > > > other languages, then they can deal with the consequences. > > > > > > Stefano Rivera (stefanor) and I offer to maintain the Python scripts in > > > devscripts. Is it enough to have at two DDs to support Python? > > > > Has this issue been resolved? Has this question been answered by > > devscripts maintainers? > > We managed to alleviate the concerns / weaken the resistance. The two > Python scripts suspicious-source and wrap-and-sort landed in the > devscripts git master branch and will be included in the upcoming > upload. Okay, thanks. What about the rest? Is this discussed some place public? This thread makes it look like there was indecision. What did I miss? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306327745.10959.2.camel@debian.tauspace.local
Re: new scripts and patches for devscripts
On Thu, 2011-03-10 at 00:26 +0100, Benjamin Drung wrote: > Am Mittwoch, den 09.03.2011, 12:26 -0500 schrieb James Vega: > > On Tue, Mar 8, 2011 at 7:12 PM, Benjamin Drung wrote: > > > Am Mittwoch, den 09.03.2011, 00:05 + schrieb Roger Leigh: > > >> On Tue, Mar 08, 2011 at 11:01:12PM +0100, Benjamin Drung wrote: > > >> > Should these script moved from ubuntu-dev-tools into devscripts? > > >> > > > >> > Most of the script are written in Python. Rewriting them to get them > > >> > included in devscripts is too much work without benefit. devscripts > > >> > would depend on python then. > > >> > > >> Most of the scripts are short. Rewriting would be fairly simple, and > > >> may be beneficial in removing the Ubuntu-specific bits. > > > > > > What speaks against having these script in python? Is python too heavy > > > for a _development_ machine? > > > > It's not just about a package dependency. It's more about restricting > > the knowledge base required for those maintaining the package. > > > > Considering that scripts are contributed to devscripts and the support > > burden is then commonly left on the shoulders of those maintaining > > devscripts instead of the original script author, it's in our interest > > to maintain a consistent set of languages that we are willing to > > support. This is currently Perl and shell. > > > > So yes, IMO, accepting scripts written in Python (or any other language) > > is too heavy. Not for a "_development_ machine", but for a maintenance > > team. If people choose to ignore our requirement and develop scripts in > > other languages, then they can deal with the consequences. > > Stefano Rivera (stefanor) and I offer to maintain the Python scripts in > devscripts. Is it enough to have at two DDs to support Python? Has this issue been resolved? Has this question been answered by devscripts maintainers? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1306006865.6282.1.camel@debian.tauspace.local
Re: Anyone looking at darcs?
On Fri, 2011-05-20 at 11:15 +0200, Sandro Tosi wrote: > On Fri, May 20, 2011 at 10:55, Tshepang Lekhonkhobe > wrote: > > It was kind because the info was offered, but it was unkind because the > > guy was ridiculed. > > you should stop speculating what others want to say (in and between > the lines) , since you're wrong. You mean 'ridicule' is too strong a word? Sorry, I didn't mean to be inaccurate. But you get the point. You could be more kind, which in effect would not have started my complaints. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1305887918.3545.3.camel@debian.tauspace.local
Re: Anyone looking at darcs?
On Thu, 2011-05-19 at 21:51 +0900, Osamu Aoki wrote: > Hi, > > On Thu, May 19, 2011 at 01:39:11PM +0200, Sandro Tosi wrote: > > On Thu, May 19, 2011 at 13:00, Tshepang Lekhonkhobe > > wrote: > > > You are sharing good info, but you could have been more kind. > > I guess Tshepang meant "kind" = "hand holding". I didn't mean that. But the negative responses don't seem to me to be a solution. If anything, someone looking at this sees nothing but immaturity. Little things like this will let others think that the Debian community isn't a friendly bunch. It's worse when it comes from an official DD. Anyways, since the person asking was pointed to the right resources anyways, why add the negativity. "No, do it this way, you dummy!". How about if that becomes, "No, do it this way". Or if that's too unsatisfying, stay away or leave a link. Have a bunch of links ready for cases where you think you've noticed a dummy. > The burden of learning such basics lies with the contributor. Lack of > such due diligence is not so welcomed. Although Sandro made a very > terse explanation from a point of view of normal life, I consider his > effort to be very informative one. I consider this to be "kind" but > "terse". It was kind because the info was offered, but it was unkind because the guy was ridiculed. It's simply not needed. It just doesn't help. It even makes people scared of asking questions. There's ways of saying that you disapprove of people lacking diligence without being negative. > > from a guy (co)maintaining 22 packages in main you could expect more > > than that. and where was rudeness? should I add flowers and kisses to > > emails? That this guy does so much work for Debian makes him deserve even more respect than usual I think. > Maybe Sandro did not need some "sarcasm" in his reply but I fully > understand his feeling and I support him ... I think here is a typical > gap of expectation around Debian. In order to reduce this kind of > tension, I recently added few reminders in mant-guide as "Social > dynamics of Debian". > > http://www.debian.org/doc/manuals/maint-guide/start.en.html#socialdynamics > > Friendly cooperation is the driving force. > * Your contribution should not overstrain others. > * Your contribution is valuable only when others appreciate it. > > Debian is not your school where you get automatic attention of teachers. > * You should be able to learn many things by yourself. > * Attention from other volunteers is a very scarce resource. > > > Osamu Good work there. I agree. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1305881741.4192.9.camel@debian.tauspace.local
Re: Anyone looking at darcs?
On Wed, 2011-05-18 at 08:31 +0200, Sandro Tosi wrote: > On Wed, May 18, 2011 at 00:10, Erik de Castro Lopo > wrote: > > Is anyone looking at getting the latest version of darcs into unstable? > > > > If not, I will have a crack at it. > > Why didn't you ask its maintainers (or at least cc them)? why didn't > you report a bug against darcs asking for the new version to be > packaged? why didn't you check darcs pts page[1], where you would have > seen they're looking for a new maintainer[2]? > > [1] http://packages.qa.debian.org/d/darcs.html > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624162 You are sharing good info, but you could have been more kind. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1305802822.9904.7.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 14:54 -0300, Ben Armstrong wrote: > On 05/06/2011 02:39 PM, Tshepang Lekhonkhobe wrote: > > I was responding to someone who said I 'supported' inclusion of proposed > > package. > > Ah, I misunderstood. My apologies. Welcome. > > Yeah, good point. So it's not enough for packager to say he will be > > responsive to problems? > > Packages, once uploaded, enter the Debian ecosystem and therefore > involve some time from many others: the security team, the ftpmasters, > the release managers, BSP participants, etc. as well as consuming > resources (archive space, autobuild time, etc.) So the cost needs to be > justified by the value to Debian. If there is no perceived value, the > package should not be added to the archive. Understood, but what's so hard about removing a package that's unloved (and moving it to some unofficial repository)? > > As I've mentioned elsewhere on this thread, it's not kool to just say > > 'no', without stating why. > > Huh. I thought Joss did say why. It's a CMS. It's PHP. That's why. :) > (and maybe that's not enough for you, but those are reasons *I* wouldn't > invest time in such an endeavour.) Actually he didn't say why. It might be implied, but not all of us know the guy well enough to know what he means. I'm curious though, why is there an objection against CMS inclusions in general? > > I'm lost there. What you mean about the mirror thing, and about the > > sarcasm thing? Where did I use sarcasm? > > If referring to Joss as "The great Josselin Mouette" was sincere and not > sarcasm, then my mistake. It had the appearance of a jab. I tried to avoid that by mentioning why I called him great. Here's more: His tireless work on Debian GNOME packaging impresses me, and that's my favorite desktop. He appears to me the most visible member of the team. I trust him to help build a solid GNOME desktop, and that's not exactly a trivial task. He's one of Debian legends. Such excellence makes it even more sad when he gets this unproductive. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304706807.20397.48.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 13:56 -0300, Ben Armstrong wrote: > We can stop CCing the bug# now, as this subthread is apparently no > longer about the ITP itself, but about "proper" conduct in discussing an > ITP. > > On 05/06/2011 01:39 PM, Tshepang Lekhonkhobe wrote: > > Strange that you read 'support' into my responses. > > By support, I hope you understand I mean the Debian project > infrastructure cost of adding another package to the archive, not user > support. That was my sole objection. Your statement here is what made me > jump in and speak up: I was responding to someone who said I 'supported' inclusion of proposed package. > > It's always convenient to have a package in > > Debian, instead of hunting for it upstream. If it rots in Debian, then > > it can easily be removed again (or left in Unstable). > > I strongly disagree. Every addition to the archive must be justified. > Your defense seemed implicitly to hinge on "zero cost" of adding a new > one (i.e. convenience trumps other concerns). Yeah, sure. I agree. My mistake. > > Actually I have never > > even heard of the proposed package, but that's not the point. I even > > mentioned that if the package sucketh (if the guy proposing it proves > > unreliable), then it can either remain in Unstable or be removed. > > That's putting the quality control on the wrong end. Nobody gets to > spend our time keeping a package in the archive as a trial of whether > it's good or not. We need to justify its inclusion first. Yeah, good point. So it's not enough for packager to say he will be responsive to problems? > > And no, you should fault others for expressing their dissent in this > > unproductive manner. > > I should? Or maybe you should read it for what it clearly is, a blunt > "minus one" vote due to the technology it's based on. And while you > write your sarcasm-tinged replies calling down other developers for > using the wrong tone, why don't you look in the mirror? As I've mentioned elsewhere on this thread, it's not kool to just say 'no', without stating why. I'm lost there. What you mean about the mirror thing, and about the sarcasm thing? Where did I use sarcasm? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304703565.20397.34.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 20:03 +0300, George Danchev wrote: > On Friday 06 May 2011 19:39:26 Tshepang Lekhonkhobe wrote: > > On Fri, 2011-05-06 at 13:24 -0300, Ben Armstrong wrote: > > > On 05/06/2011 12:14 PM, Tshepang Lekhonkhobe wrote: > > > > Q: How many content management systems written in php does Debian need? > > > > A: How about zero? > > > > > > > > Not exactly helpful. > > > > > > When developers are passionately opposed to a particular technology (and > > > not without reason here, I think,) they can be a bit blunt in expressing > > > it. The list of these goes on and on ... and while I certainly would be > > > more polite myself about expressing reservations about adding any more, > > > I'm not going to fault others for expressing their dissent. The way you > > > expressed your support seemed to me to gloss over the real cost of > > > adding a new package to the archive without any coherent argument as to > > > why this particular one was going to be no trouble at all (and/or worth > > > the trouble because it's so special). > > > > Strange that you read 'support' into my responses. Actually I have never > > even heard of the proposed package, but that's not the point. I even > > mentioned that if the package sucketh (if the guy proposing it proves > > unreliable), then it can either remain in Unstable or be removed. > > Upload to 'unstable' and see how it goes could be quite suboptimal tactics > most of the time. I'm not talking about that particular package, but not > every > package which flies in the free software skies deserves to be in Debian > archive > in my own opinion. Inclusions costs human time. I am not opposed to this. But again, that was not the point. Point was automatic 'should not be in Debian' without giving reasons. And if maintainer is willing to be on top of things, what extra work is there for anyone, except those handling NEW? > > You don't just blatantly oppose Debian inclusion without mentioning why. > > The great Josselin Mouette (yes, I really respect this guy for his > > tireless GNOME maintenance) just did that, and the rest of us are > > supposed to magically possess the history of PHP in Debian, and laugh it > > off. > > > > And no, you should fault others for expressing their dissent in this > > unproductive manner. > > Well, maybe if you look at that from a different angle, you can find it > productive as in: don't spend your time packaging that particular one, as > chances are very low for upload. I don't understand what you are saying here. My point was the manner in which the response was made. I used the word 'productive' because the guy wasn't saying why he was objecting to this particular package. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304703032.20397.27.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 13:24 -0300, Ben Armstrong wrote: > On 05/06/2011 12:14 PM, Tshepang Lekhonkhobe wrote: > > Q: How many content management systems written in php does Debian need? > > A: How about zero? > > > > Not exactly helpful. > > When developers are passionately opposed to a particular technology (and > not without reason here, I think,) they can be a bit blunt in expressing > it. The list of these goes on and on ... and while I certainly would be > more polite myself about expressing reservations about adding any more, > I'm not going to fault others for expressing their dissent. The way you > expressed your support seemed to me to gloss over the real cost of > adding a new package to the archive without any coherent argument as to > why this particular one was going to be no trouble at all (and/or worth > the trouble because it's so special). Strange that you read 'support' into my responses. Actually I have never even heard of the proposed package, but that's not the point. I even mentioned that if the package sucketh (if the guy proposing it proves unreliable), then it can either remain in Unstable or be removed. You don't just blatantly oppose Debian inclusion without mentioning why. The great Josselin Mouette (yes, I really respect this guy for his tireless GNOME maintenance) just did that, and the rest of us are supposed to magically possess the history of PHP in Debian, and laugh it off. And no, you should fault others for expressing their dissent in this unproductive manner. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304699966.20397.23.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 11:29 -0400, Scott Kitterman wrote: > On Friday, May 06, 2011 11:23:50 AM Tshepang Lekhonkhobe wrote: > > On Fri, 2011-05-06 at 09:11 -0400, Scott Kitterman wrote: > > > On Friday, May 06, 2011 08:56:21 AM Chris Warburton wrote: > > > > Programming Lang: PHP > > > > Description : ocPortal is a Content Management System for > > > > building > > > > > > > > and maintaining a dynamic website > > > > > > How many content management systems written in php does Debian need? > > > > It's not kool that you didn't even ask about how good it is. Maybe it's > > better than whatever exists in Debian currently, have you checked? My > > point is your question isn't helpful. It smacks of flaming. > > The question I should have asked is what is it's security record like. This > is an area that's rife with applications that have 'poor' security records. > Adding more to that pile would be an unfortunate burden on the security team. > > That's probably the most significant of the project wide costs adding a > package > like this brings with it. Thanks for putting your objection in a more readable/friendly form. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304697006.20397.12.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 09:11 -0400, Scott Kitterman wrote: > On Friday, May 06, 2011 08:56:21 AM Chris Warburton wrote: > > Programming Lang: PHP > > Description : ocPortal is a Content Management System for building > > and maintaining a dynamic website > > How many content management systems written in php does Debian need? It's not kool that you didn't even ask about how good it is. Maybe it's better than whatever exists in Debian currently, have you checked? My point is your question isn't helpful. It smacks of flaming. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304695430.20397.10.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 11:00 -0300, Ben Armstrong wrote: > On 05/06/2011 10:49 AM, Tshepang Lekhonkhobe wrote: > > What's up with the hate? It's always convenient to have a package in > > Debian, instead of hunting for it upstream. If it rots in Debian, then > > it can easily be removed again (or left in Unstable). > > Wrong. Every additional package costs the whole Debian project in > numerous ways. That's why we have these discussions up front on all > ITPs, so objections can be voiced. Q: How many content management systems written in php does Debian need? A: How about zero? Not exactly helpful. That was before discussing if the guy filling the ITP mentioned his readiness to respond to any RC bugs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304694881.20397.7.camel@debian.tauspace.local
Re: Bug#625865: ITP: ocportal -- ocPortal is a Content Management System for building and maintaining a dynamic website
On Fri, 2011-05-06 at 15:16 +0200, Josselin Mouette wrote: > Le vendredi 06 mai 2011 à 09:11 -0400, Scott Kitterman a écrit : > > On Friday, May 06, 2011 08:56:21 AM Chris Warburton wrote: > > > Programming Lang: PHP > > > Description : ocPortal is a Content Management System for building > > > and maintaining a dynamic website > > > > How many content management systems written in php does Debian need? > > How about zero? What's up with the hate? It's always convenient to have a package in Debian, instead of hunting for it upstream. If it rots in Debian, then it can easily be removed again (or left in Unstable). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1304689785.20397.1.camel@debian.tauspace.local
Re: Bits from the Debian Multimedia Maintainers
On Sun, Nov 14, 2010 at 04:05, Alessio Treglia wrote: > Hi! > > Since there has been a lot happening in the Debian Multimedia world > during the Squeeze release, so we figured we should give you an update > on that. Thanks for this (excellent) update. The team has been so quite that I've wondered if it's still relevant :-) [snip] > * FFmpeg 0.5.2, finally uncrippled thanks to zack! No mp3/h264 > encoder, though. (still in NEW). > * mplayer 1.0rc3, finally with mencoder enabled. Rocks!!! Less reason to go grab them goodies from the famous unofficial repository. -- blog: http://tshepang.tumblr.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=tkkvdz15wukkdx8i5z3f_nmjixtjhrh716...@mail.gmail.com
Re: Full install/removal/upgrade test results available
> Tshepang Lekhonkhobe > wajig (U) Can someone help me. I don't understand what the problem here is: http://people.debian.org/~lucas/logs/2010/11/17/wajig.log -- blog: http://tshepang.tumblr.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=6lu+m+vhfjns7fuxrfr2ek5ccmac8sd=9m...@mail.gmail.com
Re: Is a bug RC relevant if it has an influence on the health of a person
On Thu, Sep 9, 2010 at 14:34, Ben Finney wrote: > Andreas Tille writes: > >> with GNUmed we currently have a case where a bug is not RC regarding >> the computer system and would not match our criterion of RC bugs. > > Rather than RC (which is only about whether the severity of the bug is > sufficient to delay the release of Debian), what is the severity of the > bug? AFAIK, this is not the sort of package that would delay Debian's release. At worst it would just get excluded from the release. -- blog: http://tshepang.tumblr.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikeosmx43+45hxsq0rfkv3qnuc0nvu4atw60...@mail.gmail.com
Re: Is a bug RC relevant if it has an influence on the health of a person
On Thu, Sep 9, 2010 at 11:58, gregor herrmann wrote: > On Thu, 09 Sep 2010 11:40:49 +0200, Andreas Tille wrote: > >> with GNUmed we currently have a case where a bug is not RC regarding the >> computer system and would not match our criterion of RC bugs. However, >> the influence of this bug might harm the health of patients of the >> doctor who might use this version of GNUmed. > > Doesn't that simply count as severity: grave - "makes the package in > question unusable or mostly so"? > >> IMHO we should enhance our definition for what >> RC critical means. > > IMO "grave" doesn't only mean "segfaults at start" etc. but also > "produces garbage, shows completely wrong results, doesn't fulfill its > core purpose, ...". ...risks patients' lives, ... Definitely RC, 'grave' severity. -- blog: http://tshepang.tumblr.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=gbox4nmrx457v6qt57dzxcgfy7qeqzce3z...@mail.gmail.com
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Tue, Sep 7, 2010 at 15:18, Josselin Mouette wrote: > Le mardi 07 septembre 2010 à 11:17 +0200, Salvo Tomaselli a écrit : >> On Tuesday 07 September 2010 10:47:08 Josselin Mouette wrote: >> > Oh, please. If you want to setup such schemes, why would you not want to >> > spend 5 minutes to configure apache or lighttpd instead of spending at >> > least the same time to configure such an obscure piece of software? >> > >> > If all you care about is sharing a few files in the simplest way, there >> > are much better tools to do it, like gnome-user-share. >> >> 1 you are assuming to have root permissions (read my previous email) > > No. gnome-user-share does not need root permissions. > >> 2 you are assuming to be working on a desktop > > Well that’s usually the case when you don’t have root permissions. > >> 3 you are assuming you want to share the same file all the time. But this >> might not be the case, and change the configuration every time you want to >> share a different file could annoying. > > That’s precisely why gnome-user-share was written. Thanks for making my > point. > > Now if you could give a hand in maintaining important packages, like > apache2 and its 90 open bugs, it would help more than packaging your pet > web server which will be of use for at best 2 users. If there's two options: (a) someone packages obscure software for Debian (b) me having to go to obscure software's website and run "setup.py" myself I'll choose (a) any day. I find it highly convenient when I hear of some piece of software, and discover that it's just an "apt-get install" away. Would be nice to have more maintainers for core packages, but what if it's just not interesting. I'll rather have the uninterested hacker package something new, than not do anything at all for Debian. If you are worried about package quality, burden on security team, blah, I expect an RC bug will be filed and so that the package can be removed from Testing. If it's neglected, then it can be removed from Unstable. Let Debian be the wonderful supermarket it is. -- blog: http://tshepang.tumblr.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinwj0kqxq54jztfrwoyuhnvic==eyahxqc07...@mail.gmail.com
Re: [OT] Bug#560863: ITP: lamson -- The Python SMTP Server
On Sun, Dec 13, 2009 at 13:03, Ben Finney wrote: > Tollef Fog Heen writes: > >> ]] Sebastian Otaegui >> >> | * Avoid aliases forever! Lamson uses friendly regular expressions >> | and FSM-based routing. >> >> What does the flying spaghetti monster have to do with email routing? > > You can't disprove the flying spaghetti monster has no involvement with > email routing. Therefore he must be involved. LOL -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packages in section python/perl simply because implemented in python/perl
On Sat, May 24, 2008 at 11:22 AM, Sami Liedes <[EMAIL PROTECTED]> wrote: > (NOTE: Am I the only one who thinks descriptions, especially short > descriptions as in phenny, usually shouldn't tell what language was > used to implement the program? It's just not relevant to the user.) Me agrees. Looks more of irresponsible advertising to me. > Well, I don't know if you agree with me that "written in Python" is a > poor reason to put a package in the python section, I couldn't find > anything about it in the New Maintainers' Guide, for example. But if > you do, perhaps a note should be added to the NMG, given how common > this seems to be. Me agrees too. -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: triggers wishlist
Anyone out there? On Tue, Apr 1, 2008 at 9:27 AM, Tshepang Lekhonkhobe <[EMAIL PROTECTED]> wrote: > On Mon, Mar 31, 2008 at 10:28 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > > On dim, 2008-03-30 at 16:25 -0400, Joey Hess wrote: > > > Things I want to see use triggers, in approximate priority order: > > > > > > - scrollkeeper > > > > It will probably be deprecated soon, so I don't think it is necessary to > > put effort into it. > > Would rarian-compat be the replacement? If so, what's the delay? -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: triggers wishlist
On Mon, Mar 31, 2008 at 10:28 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > On dim, 2008-03-30 at 16:25 -0400, Joey Hess wrote: > > Things I want to see use triggers, in approximate priority order: > > > > - scrollkeeper > > It will probably be deprecated soon, so I don't think it is necessary to > put effort into it. Would rarian-compat be the replacement? If so, what's the delay? -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libdb4.* madness in unstable
On 10/16/07, Michael Biebl <[EMAIL PROTECTED]> wrote: > Today, while browsing through aptitude, I noticed that I had the > following bdb versions installed: > > version: # of packages depending on it (apt-cache rdepends) > libdb4.2 40 > libdb4.3 26 > libdb4.4 55 > libdb4.5 64 > libdb4.6 40 > > Having 5 different versions of one library is just insane imho. What are > the reasons, that we still carry around the older versions, like 4.2 and > 4.3? Is there software which doesn't build against newer versions, are > there other reasons? > Wouldn't it make sense to limit the number of bdb version in the archive > to two or max. three? Interesting because I was wondering about the same thing, and even worse is that each of those takes way too many CPU cycles to build. -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Development environments.
On 4/23/07, Warren Turkal <[EMAIL PROTECTED]> wrote: On Monday 23 April 2007 12:58, Alan Ezust wrote: > let's say you need to build from source a program such as "gimp" which has > many library dependencies. You don't know what they are, and you want > debian to auto-install the -dev packages you need. apt-get build-dep is > your friend. Speaking of which, will aptitude ever have this functionality? It would be nice to get the markauto goodness from aptitude when installing builddeps. APT 0.7, available in Experimental, has got automatic removal of unneeded rdepends, though I haven't checked if it provides the above needed functionality, nor have I even tested it at all. -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mandatory -dbg packages for libraries?
On 4/23/07, Joey Hess <[EMAIL PROTECTED]> wrote: Anyway, doubling the size of the archive is less of an issue than it might have been in the past, since we've done the archive split, and since ftp-master has 1.4 Terabytes of disk with half that unused, but it is still a concern, for mirrors, number of DVDs, etc. It would be nice if the standard iso images that Debian makes available could be made to exclude -dbg packages as a trade-off. It actually felt painful someday when doing jigdo on the archive, only to see loads of -dbg packages getting downloaded, and knowing I wasn't ever gonna use 'em. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (Last few) bits from the 2IC
On 4/17/07, Steve McIntyre <[EMAIL PROTECTED]> wrote: then we had the result of the Debian Project Leader election. For the second year running, I came second in a close decision[7] (boo! *grin*), this time to Sam Hocevar instead of AJ. Congratulations to Sam, and I wish him all the best for his term. And a final vote of thanks to AJ for all his efforts in the last year - it's been great working with him. That's amazing. I didn't even notice that you were 2nd best for two years in a row. Isn't this maybe a record? The best DPL loser ever :-) Anyways, do you plan to try again next time around. -- my place on the web: floss-and-misc.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The number of etch installations is rocketing...
On 4/12/07, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: Looking at the submission numbers from http://popcon.debian.org/>, I am happy to report that the number of Etch installations is increasing fast. Here are the number of submissions collected by popularity-contest, with the increment. It is easy to see when Etch was released. date submissions change 2007-04-03 32311 +55 2007-04-04 32400 +89 2007-04-05 32504+104 2007-04-06 32525 +21 2007-04-07 32595 +70 2007-04-08 32722+127 2007-04-09 33639+917 2007-04-10 34530+891 2007-04-11 35420+890 Now I just wonder how long the rate of increase will keep up. :) Please keep on sending these interesting stats, perhaps once-per-week, to some blog or some mailing list. I'll be real glad. Thanks... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote: On Tue, Apr 10, 2007 at 11:40:27AM +0200, Tshepang Lekhonkhobe wrote: > On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> > wrote: > >I work in a science lab and can tell you that even though we do have > >commercial software (Matlab, Maple, CPlex and other scientific > >computation programs, some of which are at least twenty years ahead of > >any free equivalent), we do use debian and from there also use it > >elsewhere (our homes, our students' workstations, etc.). Should we > >become unable to do our daily job with Debian, yes, we would have to > >switch distributions, which would be a pity since this is a place where > >computer scientists are made. > > I'm pretty interested in knowing which programs are so advanced as to > being 20 years ahead of libre equivalents, and why, if you don't mind. For example, CPlex (a mathematical programming optimizer) is considered much better than any free (even free as beer) program, having no equivalent for e.g. quadratic constraints problems. Maple is also considered much more advanced than Octave especially toolboxes available only in Maple. I may have exaggerated by saying 20 years, but I will not settle for less than 10. And we need those anyway to compare results obtained by one software against the other. This is interesting. I often hear people citing pros and cons of FLOSS and commercial stuff, but don't remember anyone stating such extravagant development gaps as 10 years or so. I'd like to hear opinions of others who have also used those Cplex Maple, and whatever else you may have in mind. This however brings to mind libre CAD stuff which truly lags behind. The reason for the advance is that the most brilliant people of one small research field unite to build some software company. They recruit the most brilliant students, and can keep this for a long time (not eternally, I believe, but long enough). Maple, Cplex and Matlab all date from before 1990 where free software became (at least in france) commmon place enough so that new projects (see Scilab) would be at least partly open source. I've got an idea that some software is targeted at such a narrow userbase (CAD for example) that volunteer development seemes unjustified. In such cases, it's nice when academy and business lend their hand. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 64-bit transition deadline (Re: Etch in the hands of the Stable Release Managers)
On 4/10/07, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote: On Tue, Apr 10, 2007 at 12:00:08AM -0700, Sean Perry wrote: > I haven't seen much Debian in the last 6 years in the commercial > world. RH rules that roost. If people have chosen closed source, then > they likely are also paying for an enterprise edition of their free > OS too. Linux == Redhat was done in like 2000. Time to worry about > other things. I work in a science lab and can tell you that even though we do have commercial software (Matlab, Maple, CPlex and other scientific computation programs, some of which are at least twenty years ahead of any free equivalent), we do use debian and from there also use it elsewhere (our homes, our students' workstations, etc.). Should we become unable to do our daily job with Debian, yes, we would have to switch distributions, which would be a pity since this is a place where computer scientists are made. I'm pretty interested in knowing which programs are so advanced as to being 20 years ahead of libre equivalents, and why, if you don't mind. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Nice use of profanity...(Re: GNOME and trolls)
On 2/20/07, Russell Coker <[EMAIL PROTECTED]> wrote: On Tuesday 20 February 2007 09:30, Manoj Srivastava <[EMAIL PROTECTED]> wrote: > > Why the gratuitous insult to Indian and Indians here? Or do > > you think only one country has people who deserve pity? there are > > no unfortunate people in developed countries? > > It has been gently pointed out to me that the sentiment could > have been in regards to the bombing on the train earlier today, and > not a commentary on indian in general. Is the Indian train bombing somehow different from all other terrorist acts in a way that makes it relevant to a discussion of GNOME? it's different in that it's recent... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about gstreamer0.8 and python2.3 removal
On 2/9/07, Loïc Minier <[EMAIL PROTECTED]> wrote: On Fri, Feb 09, 2007, Tshepang Lekhonkhobe wrote: > Pretty surprising. Was there a discussion in which this decision was > made or is this just the assumed position? <http://lists.debian.org/debian-devel/2006/12/threads.html#00131> I saw that thread which seemed to die off without a clear indication of the decisions taken as regards removal, hence 'assumed' position: One guy wants gst0.8 removed and another wants to keep it in due to goobox, there's some arguments, and.. nothing (not even mails to release or security team). This situation is similar to the GNOME 2.14 vs. 2.16 for Etch thing that I only noticed accidentally, or perhaps some people assumed everybody reads planet.debian.org and other DD blogs... sorry if you feel this is noise, but there should really be better comms...
How many packages in Sid should reach Etch?
Hi, The useful bjorn,haxx.se/debian lists nearly 2000 packages trying to enter Testing which keeps on growing these days due to manual hinting of course. By I actually wonder if the release team is able to keep up. I know there's certain kinds of packages never meant to reach Testing, but is there an automated way of determining exactly how many packages are actually intended to reach Etch? A more silly and related question: If the 100 RC bugs were suddenly fixed and d-i were released tomorrow, would the dozens of non-RC hint requests (translations, important bugs) be ignored and Etch be released anyways? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: about gstreamer0.8 and python2.3 removal
On 2/9/07, Loïc Minier <[EMAIL PROTECTED]> wrote: On Fri, Feb 09, 2007, Tshepang Lekhonkhobe wrote: > It's been a while since someone mentioned removal of gst0.8 and py2.3 > and wonder what's going on. Concerning GStreamer 0.8, teatime, goobox and muine remain rdeps in unstable, so GStreamer 0.8 is kept for etch. Pretty surprising. Was there a discussion in which this decision was made or is this just the assumed position? By the way, teatime and muine got gst0.10 patches. It would just be interesting to see if that patched version of muine would reach Etch since it's also an upstream version and is in experimental. thanks for the reply
about gstreamer0.8 and python2.3 removal
Hi, It's been a while since someone mentioned removal of gst0.8 and py2.3 and wonder what's going on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upgrade Experiences (27 Sarges -> Etch, and counting)
On 2/5/07, Maarten Verwijs <[EMAIL PROTECTED]> wrote: [snip] So as far as I'm concerned: Etch is ready to go! Thanks for all the hard work! Debian is still the one and only distribution for me. It Just Works. Thanks for your efforts. Heroic distro, lovely testimony... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package
On 1/2/07, Tshepang Lekhonkhobe <[EMAIL PROTECTED]> wrote: On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > On Tue, Jan 02, 2007 at 04:28:59PM +0200, Tshepang Lekhonkhobe wrote: > > On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > > Why not have an extra /usr/share/doc/$source-name directory in case a > > binary package of the same name doesn't exist or is not found to be > > installed. This would be a problem when dependencies change, but on > > package removal, /usr/share/doc/$source-name would be left alone if > > there remains binary packages built from that source package. > > That's what $package-common packages are for. But just to hold the > copyright and changelog that's an overkill because those packages would > need some kind of garbage collection somehow and that i'm quite sure > that it would use more mirror resources than the repeated changelogs. > > Well all in one it's not worth the effort, and has many drawbacks > IMHO. I'd say that's a thing you may consider when you already need a > $package-common for your packaging, but it's not necessarily a good > idea. > > just to know what we are talking about, on my system: > > du /usr/share/doc/*/changelog.Debian.gz: 16M > du /usr/share/doc/*/copyright: 15M > du /usr/lib/iceweasel/firefox-bin: 15M > > so well, if it's not nothing, it's still quite small, and I can't > imagine a system where 30M is an issue nowadays (well except PDA's or > so, but here the whole /usr/share/doc is an issue at once anyway, like > Don already explained it - on my system /usr/share/doc is 234M big). Pretty well-justified that this would be a useless effort. Along with Don's mention that binary packages don't have to be the same version it just shows that my proposal sucks. thanks By the way, this proposal was made because I browsed through /usr/share/doc/$package/changelog.Debian.gz to find that they were the same for different binary packages and expecting otherwise. I guess it's too much trouble doing separate changelogs for binary packages. One other important note: If a large src package builds multiple binary packages, a small change on one of those binary packages (say OOo) which is unrelated to the other binary packages, will cause all those other binary packages to be rebuilt and require upgrading, which seems like a waste. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package
On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: On Tue, Jan 02, 2007 at 04:28:59PM +0200, Tshepang Lekhonkhobe wrote: > On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: > Why not have an extra /usr/share/doc/$source-name directory in case a > binary package of the same name doesn't exist or is not found to be > installed. This would be a problem when dependencies change, but on > package removal, /usr/share/doc/$source-name would be left alone if > there remains binary packages built from that source package. That's what $package-common packages are for. But just to hold the copyright and changelog that's an overkill because those packages would need some kind of garbage collection somehow and that i'm quite sure that it would use more mirror resources than the repeated changelogs. Well all in one it's not worth the effort, and has many drawbacks IMHO. I'd say that's a thing you may consider when you already need a $package-common for your packaging, but it's not necessarily a good idea. just to know what we are talking about, on my system: du /usr/share/doc/*/changelog.Debian.gz: 16M du /usr/share/doc/*/copyright: 15M du /usr/lib/iceweasel/firefox-bin: 15M so well, if it's not nothing, it's still quite small, and I can't imagine a system where 30M is an issue nowadays (well except PDA's or so, but here the whole /usr/share/doc is an issue at once anyway, like Don already explained it - on my system /usr/share/doc is 234M big). Pretty well-justified that this would be a useless effort. Along with Don's mention that binary packages don't have to be the same version it just shows that my proposal sucks. thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package
On 1/2/07, Pierre Habouzit <[EMAIL PROTECTED]> wrote: On Tue, Jan 02, 2007 at 03:44:10PM +0200, Tshepang Lekhonkhobe wrote: > Hi, > > I find it wasteful to install the same changelogs (both Debian and > upstream) in binary packages which share the same sources. Why not > have symlinks in place of these and perhaps an extra /usr/share/doc > directory named the same as the source package in case a binary > package of the same name doesn't exist. > > Maybe this is not the right time but then maybe someone should > convince me that I'm proposing a bad idea. the problem is, you can only do that if you have one of the binary package that is always installed with any of the other, else you will have dangling symlinks, and it's prohibited by the policy (no to mention that it would be quite useless !) Why not have an extra /usr/share/doc/$source-name directory in case a binary package of the same name doesn't exist or is not found to be installed. This would be a problem when dependencies change, but on package removal, /usr/share/doc/$source-name would be left alone if there remains binary packages built from that source package. Sorry if I seem to disregard the rest of your mail... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package
Hi, I find it wasteful to install the same changelogs (both Debian and upstream) in binary packages which share the same sources. Why not have symlinks in place of these and perhaps an extra /usr/share/doc directory named the same as the source package in case a binary package of the same name doesn't exist. Maybe this is not the right time but then maybe someone should convince me that I'm proposing a bad idea. thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Fwd: FC6 downloads and installs
Hi, Could we have something like this after release: -- Forwarded message -- From: Max Spevack <[EMAIL PROTECTED]> Date: Nov 16, 2006 11:39 PM Subject: FC6 downloads and installs To: fedora-announce-list@redhat.com Pardon the widest possible distribution, but I hope that people within Red Hat will take this email as good news about the impact of Fedora Core 6, and as a testament to the size and strength of the Fedora Community. I'd also like to point out the incredible work of the Fedora Infrastructure team in helping to get us to the point where we know enough to even write this email. Particulary Mike McGrath. These are the sorts of metrics that we've been dying to get, and while our various attempts at collecting them spawned many threads of the right or wrong way to do it, I think we've stumbled across a good solution. Today is the 24th day -- about 3.5 weeks -- since FC6 was released. Since release, we've been tracking the number of unique IP addresses that check in via yum for updates. This metric is much more useful than tracking downloads, because it demonstrates actual *installed instances* of FC6 that are making a connection back to our servers in search of updated software. A few minutes ago, we crossed over the 300,000 mark. That's 300,000 different IP addresses that have checked for any updated software in Fedora Core 6. If you simply divide it out, that averages to about 12,500 per day, or 8.7 every minute. And basically, those are *new installs* of FC6. That doesn't take into account proxies and firewalls that can make hundreds of servers all look like they are coming from the same IP, so the "real" number is probably even higher than that. Additionally, fedoraproject.org saw just over 640,000 unique visitors in October, and so far in November has seen just over 300,000 unique visitors. A more detailed write up is on the fedoraproject.org page: http://fedoraproject.org/wiki/ZodStats -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FAQ, Re: new mplayer
On 9/26/06, A Mennucc <[EMAIL PROTECTED]> wrote: hi everybody I just now notice the debate on mplayer going on; so here are a few answers [snip: mplayer is okay to go in] I don't know if this is answered elswhere, but how come it is still stuck in NEW? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On 10/19/06, Mike Hommey <[EMAIL PROTECTED]> wrote: Waw, actually, i was trying to be less aggressive... Anyways, since I'm too pissed and since I see no reason to put myself in that mood any further, I'm taking a few days off Debian, which means my current work on seamonkey^Hiceape will be on hold. All the work in progress on my currently maintained packages will be on hold too. If you want iceape in shape for etch if we are anything near a freeze, well, get your fingers out of your asses, as we say in french. I would take it out if it was in there, but please don't be pissed off so soon. Continue hacking away and let's have the best release ever :-) I really want to see Seamonkey in Etch, and you even asked the RM's to allow you to upload it (version 1.1) when released later this month. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug mass filling
On 10/19/06, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: [Aurelien Jarno] > I have just run lintian on all the archive (amd64) for both binaries and > sources, and the results are a bit scary. It looks like a lot of > maintainers are uploading their packages, and don't really care with the > policy. What is the technical problem triggered by the packages with this lintian message? Is the autobuilders able to build these packages? If the autobuilders fail, I recommend you report that as a important or serious problem, and it it isn't, I recommend you report it as a normal bug. Doesn't policy violation warrant Critical severity? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian Installer] General release plan for RC1
On 10/10/06, Josselin Mouette <[EMAIL PROTECTED]> wrote: The current plan is to ship GNOME 2.14 in etch [1]. This was a hard decision to make, but we prefer shipping a rock-solid and polished 2.14 version rather than a buggy 2.16 version with which Ubuntu is having many issues. [1] http://oskuro.net/blog/freesoftware/gnome-2.16-etch-2006-10-06-21-45 If a decision like this happens, could you guys please post it to the relevant debian lists, like debian-gtk-gnome and/or debian-release, since I only bumped into the info by chance. thanks... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian Installer] General release plan for RC1
On 10/8/06, Loïc Minier <[EMAIL PROTECTED]> wrote: On Sun, Oct 08, 2006, Attilio Fiandrotti wrote: > Just today mike emmel fixed the "boom" bug, it should technically > possible switching to GTK+ 2.10.x. Repeating this here for other readers: 2.10.6-2 in experimental was uploaded today with the fix. So are getting GNOME 2.16 for Etch? Frans Pop scared me a bit saying we are stuck with 2.14 :-(
Re: congratulations to the X team!!
On 7/15/05, Miles Bader <[EMAIL PROTECTED]> wrote: > FWIW, I previously had xorg from Ubuntu installed, and upgrading from > that to Debian's xorg _didn't_ go smoothly: the file "/etc/X11/Xsession" > was created by two packages, x11-common [debian], and xorg-common > [ubuntu], and in upgrading tried to install x11-common before removing > xorg-common. > > I ended up downgrading to xfree86 from testing, and then upgraded back up > to xorg from unstable (and all that went smoothly). > > [I know none of that is supported, but just FYI... :-] > > -Miles > -- > ((lambda (x) (list x x)) (lambda (x) (list x x))) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Hello, I was also using ubuntu's xorg on Sid, but unlike you I am still unable to install xserver-xorg and xserver-common or even xserver-xfree86 from testing. This means I can't run GNOME. Can you help? malebo...
