Re: RFC: bringing back task packages
Le Fri, Feb 18, 2011 at 10:51:05AM +0100, Adam Borowski a écrit : > > On the contrary, I don't see what an input system would be good for. How > many languages can you write? The one from the country where I was born, and the one from the country that was kind enough to give me a work visa :) > Such a task would be useful only for installs that are meant to cater to > many users from all around the world -- a very rare occurence, while > cluttering and potentially slowing down the systems of everyone else. At least for Japanese, the input system is not active by default when starting GNOME with a French or English locale. One has to enable it, for instance with im-switch. I do not know how invasive are other input sytems. But if they are not, I thing that they could be part of a ‘I have disk space’ i18n task. I would not mind spending a couple of gigabytes if this would make my computer ready for use for anybody on this planet. For this, we need also to install most translations available. This is one of the rare things I miss from Macintosh. I always feel sorry that, while when I borrow a Mac I can switch it to French, when I lend my Debian, people can not switch it to Japanese unless I prepared it in advance. Have a nice day, -- Charles -- 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/20110219040416.gc18...@merveille.plessy.net
Wanted: maintainer for git's emacs support
Hi, None of the current Debian git maintainers seem to use emacs. This means git's emacs support[1] does not get as much care as it deserves: see for example bugs #611936, #611931, #611932, #611933, #611934, #577834, and #611935. The upstream maintainer is very friendly and responsive though he doesn't seem to have much time for it these days. Users are friendly and responsive, too. So I wonder: - would anyone be interested in adopting this code in Debian? - if not, should we be shipping it? Thoughts welcome. (Actions even more so. :)) Jonathan [1] /usr/share/doc/git/README.emacs -- 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/20110219031838.GC29369@elie
Re: Default Homedir Permissions
On Viernes 18 Febrero 2011 18:44:25 Ron Johnson escribió: > On 02/18/2011 07:26 AM, Noel David Torres Taño wrote: > > On Jueves 17 Febrero 2011 22:18:25 Ron Johnson escribió: > >> On 02/17/2011 08:58 AM, Roger Leigh wrote: > >> [snip] > >> > >>> Should it be locked down like Fort Knox? > >> > >> There's a heck of a lot of middle ground between "Fort Knox" and > >> "Hippy Commune". > > > > We are not a hippy comune, just two married people, but I like to hear > > music from my wife's home, and she uses to see documents that are on my > > home, so the actual default fits quite well for 90% of computers out > > there: home computers. > > One solution is be ~/Shared/Music & ~/Shared/Documents. That's more complicated than the actual simpler solution > > Another solution is "groups". (If you want to use a computer, you > should learn how to use it...) That's more complicated too... I use that only when write access is needed > > A third solution is moving all the shared "stuff" out of $HOME and > into a separate partition symlinked back to $HOME. That needs to be thought on on installation, and moreover complicates security copies. [...] > > > Think too on fathers accessing their minor child homes, > > The root password gets me just about anywhere I want to go. root access is just for more serious things, like system administration, and it is recommended not to run graphical apps as root, so it is not the solution, just your broken workaround over an actually non existant problem > > > offices in which > > > > documents are property of the bussiness and not of any worker, etc. > > Since the documents are the property of the business, not the > workers, they should be in shared folders anyway. Why? The default on creating a document is to save it on user's home, just let it not to be private. There a re a lot of people happy with the actual default, so the best solution is to keep it as is, and allow those admins who need it to change the behaviour on their systems only Noel er Envite -- 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/201102182240.12738.env...@rolamasao.org
Re: Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
Peter Samuelson p12n.org> writes: > > > Description : next generation movie player for Unix-like systems > > > > > >MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, > > >QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files, > > >supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It > > >can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies. > > > > > >Another big feature of MPlayer is the wide range of supported output > > >drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB, > > > > > The text above is copied from the existing mplayer package. It is > > > > The long description really needs a rewrite. > > Maybe ... but mentioning all those file formats _is_ pretty useful for > 'apt-cache search' purposes. I know we're all supposed to use tags for > such things now, but I find 'apt-cache search' a lot easier than > figuring out what tag I should be looking for. That file format list is missing at least one of the major container formats (Matroska). Some of the listed ones are very obscure; I think mentioning ability to play back various audio-specific formats (none of which are listed now) would be at least as important. The rest of the description is worse. The following codec section is meaningless and misleading (most codecs now come from libavcodec; I think about nobody uses XAnim for example). More than half the lines in the description are about video output drivers, and mostly list completely obscure features that very few will care about. The drivers you may reasonably want to use on Linux are VDPAU (missing from the description), OpenGL and XVideo. Plain X11 can be a fallback if your system doesn't support any proper video output method. The rest are mostly special cases and/or obscure unmaintained crap which doesn't belong in the package description. -- 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/loom.20110218t224337-...@post.gmane.org
Bug#613999: ITP: py3dns -- DNS client module for Python3
Package: wnpp Severity: wishlist Owner: Scott Kitterman * Package name: py3dns Version : 3.0.0 Upstream Author : Stuart D. Gathman * URL : http://http://sourceforge.net/projects/pydns * License : PSF Programming Lang: Python 3 Description : DNS client module for Python 3 This Python 3 module provides an DNS API for looking up DNS entries from within Python 3 modules and applications. This module is a simple, lightweight implementation. It is not as complete as python-dnspython, but is useful for many common applications. ITP Note: Binary will be python3-dns. This is the Python 3 port of python-dns. -- 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/20110218200544.29945.63740.reportbug@localhost6.localdomain6
Re: Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
[Uoti Urpala] > > Description : next generation movie player for Unix-like systems > > > >MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, > >QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files, > >supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It > >can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies. > > > >Another big feature of MPlayer is the wide range of supported output > >drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB, > > > The text above is copied from the existing mplayer package. It is > > The long description really needs a rewrite. Maybe ... but mentioning all those file formats _is_ pretty useful for 'apt-cache search' purposes. I know we're all supposed to use tags for such things now, but I find 'apt-cache search' a lot easier than figuring out what tag I should be looking for. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- 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/20110218201547.gd10...@p12n.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
On 02/18/2011 05:42 AM, Axel Beckert wrote: Hi, Mike Hommey wrote: - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. That would be my favourite. I use Conkeror (which is a XULRunner application and hence depends on xulrunner) with 3.6 since it is in experimental and it works without problems since a year or so. Ubuntu has the Debian package with just slight modification of some defaults together with xulrunner-1.9.2 in Lucid 10.04 LTS. They just had to backport a few upstream fixes. [snip] Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. Right. That's why I want to see 3.6 in unstable as soon as possible independently of the state of 4.0. I concur with Axel. Been using iceweasel 3.6 since soon after it hit experimental, and stuff like vlc/unstable work like a champ. -- "The normal condition of mankind is tyranny and misery." Milton Friedman -- 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/4d5ec1e9.2040...@cox.net
Re: Default Homedir Permissions
On 02/18/2011 07:26 AM, Noel David Torres Taño wrote: On Jueves 17 Febrero 2011 22:18:25 Ron Johnson escribió: On 02/17/2011 08:58 AM, Roger Leigh wrote: [snip] Should it be locked down like Fort Knox? There's a heck of a lot of middle ground between "Fort Knox" and "Hippy Commune". We are not a hippy comune, just two married people, but I like to hear music from my wife's home, and she uses to see documents that are on my home, so the actual default fits quite well for 90% of computers out there: home computers. One solution is be ~/Shared/Music & ~/Shared/Documents. Another solution is "groups". (If you want to use a computer, you should learn how to use it...) A third solution is moving all the shared "stuff" out of $HOME and into a separate partition symlinked back to $HOME. $ dir Music lrwxrwxrwx 1 me me 21 2009-03-20 16:30:56 Music -> /data/big/share/music/ $ dir /data/big/share/music/ total 44856 drwxr-xr-x 16 me all_ages 4096 2009-03-20 16:31:12 ./ drwxrwxr-x 6 me all_ages 54 2011-01-10 16:03:46 ../ -rwxr-xr-x 1 me all_ages 13624815 2006-07-14 15:35:06 060714PodcastBigelowAstronaut.mp3* -rwxr-xr-x 1 me all_ages 2133908 2006-06-06 23:40:53 4400_theme_A_Place_In_Time.mp3* drwxr-xr-x 173 me all_ages 8192 2010-12-06 20:43:09 artists/ -rwxr-xr-x 1 me all_ages 1397888 2006-06-29 10:19:48 billy_west.mp3* drwxr-xr-x 2 me all_ages 4096 2007-09-04 19:55:41 cadences/ drwxr-xr-x 2 me all_ages6 2003-12-27 11:48:50 Childrens/ drwxr-xr-x 14 me all_ages 4096 2010-12-06 21:15:09 Classical/ drwxr-xr-x 2 me all_ages 4096 2007-12-07 10:24:50 Country/ lrwxrwxrwx 1 me all_ages 14 2011-01-10 12:58:54 Disney -> artists/Disney/ -rwxr-xr-x 1 me all_ages 644906 2004-01-24 15:48:55 drwho2.mp3* -rwxr-xr-x 1 me all_ages 1216775 2004-01-24 15:49:38 drwho3.mp3* -rwxr-xr-x 1 me all_ages 368856 2004-01-24 15:48:27 drwho.mp3* drwxr-xr-x 2 me all_ages 4096 2009-12-08 18:08:25 Folk/ drwxr-xr-x 5 me all_ages 4096 2007-12-08 13:50:47 Holiday/ drwxr-xr-x 2 me all_ages 88 2007-12-06 19:38:22 Jazz/ drwxr-xr-x 2 me all_ages 125 2010-04-04 09:45:56 Lite_Rock/ drwxr-xr-x 2 me all_ages 73 2010-10-16 17:20:22 R&B/ drwxr-xr-x 2 me all_ages 4096 2010-10-16 18:57:47 Rock/ drwxr-xr-x 2 me all_ages 4096 2010-12-06 21:14:35 Soundtracks/ drwxr-xr-x 2 me all_ages6 2007-05-31 09:51:03 streams/ -rwxr-xr-x 1 me all_ages 23748420 2006-04-11 11:35:17 SXSW06.INT.20060311.DanielGilbert.mp3* drwxr-xr-x 13 me all_ages 4096 2007-12-08 13:50:34 various/ -rwxr-xr-x 1 me all_ages 2610675 2006-08-20 22:21:56 Yugo.mp3* Think too on fathers accessing their minor child homes, The root password gets me just about anywhere I want to go. offices in which documents are property of the bussiness and not of any worker, etc. Since the documents are the property of the business, not the workers, they should be in shared folders anyway. -- "The normal condition of mankind is tyranny and misery." Milton Friedman -- 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/4d5ebe09.5000...@cox.net
Re: Bug#613986: ITP: run -- tool for sampling time and memory usage
On pe, 2011-02-18 at 18:30 +0100, Thomas Krennwallner wrote: > Package: wnpp > Severity: wishlist > Owner: Thomas Krennwallner > > > * Package name: run > Version : 1.4 > Upstream Author : Armin Biere and Toni Jussila > * URL : http://fmv.jku.at/run/ > * License : BSD > Programming Lang: C > Description : tool for sampling time and memory usage > > run is a tool for sampling time and memory usage of a program and its > children using the proc file system of Linux. Time and space limits > are also supported. It is very helpful for benchmarking and running > competitions. It also supports limits on wall clock time and thus can > control runs of multi-threaded programs on multi-core machines as > well. This sounds like a very interesting tool to me, since I've been wanting to write something similar myself. I look forward to seeing it in the archive. However, the name is perhaps a tad generic. Would it be possible for you to rename it in Debian to something less generic? -- 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/1298052079.22676.66.camel@tacticus
Re: Request for Comments: Planned removal of ddrescue
Hello Mika et all, Michael Prokop wrote: I'm the maintainer of the ddrescue and gddrescue packages. I plan to drop the ddrescue package. IMHO dropping the gddrescue package and moving GNU ddrescue to the ddrescue package (replacing dd_rescue) is the least confusing solution for the users in the long term. I suppose such replacement may be complicated and create a lot of problems in the short term, but I still think it is the best solution in the long term. I guess many people expect to find GNU ddrescue in the ddrescue package, and if this package is dropped they may wrongly conclude that Debian does not provide GNU ddrescue instead of searching for the, unknown to them, gddrescue package. And as 1) the executable names are different, and 2) ddrescue is mainly used by humans instead of scripts, maybe the short term problems created by the proposed replacement aren't so serious after all. Best regards, Antonio. -- 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/4d5ea52e.80...@teleline.es
Bug#613986: ITP: run -- tool for sampling time and memory usage
Package: wnpp Severity: wishlist Owner: Thomas Krennwallner * Package name: run Version : 1.4 Upstream Author : Armin Biere and Toni Jussila * URL : http://fmv.jku.at/run/ * License : BSD Programming Lang: C Description : tool for sampling time and memory usage run is a tool for sampling time and memory usage of a program and its children using the proc file system of Linux. Time and space limits are also supported. It is very helpful for benchmarking and running competitions. It also supports limits on wall clock time and thus can control runs of multi-threaded programs on multi-core machines as well. -- 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/20110218173058.18570.38703.report...@gluck.kr.tuwien.ac.at
Re: [Adduser-devel] Default Homedir Permissions
Stephen Gran writes ("Re: [Adduser-devel] Default Homedir Permissions"):
> I don't want to prolong this thread, but this seemed useful to answer.
Thanks.
> I certainly have no intention of changing the default on my own.
> My hope is that Debian is used in ways I can't imagine, and I can not
> begin to cater to all of the variety of needs that current and future
> users will want. I think that 0755 as a default plus the ability to
> alter adduser.conf is enough flexibility to allow admins to create users
> as they see fit, while still catering to the most common case out of the
> box. No matter what we pick, someone will be unhappy.
Yes.
Thanks for the clarification. That means those of us who support the
status quo can let the discussion die.
Ian.
--
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/19806.39631.614560.524...@chiark.greenend.org.uk
Re: Default Homedir Permissions
On Fri, Feb 18, 2011 at 2:26 PM, Noel David Torres Taño wrote: > On Jueves 17 Febrero 2011 22:18:25 Ron Johnson escribió: >> On 02/17/2011 08:58 AM, Roger Leigh wrote: >> [snip] >> >> > Should it be locked down like Fort Knox? >> >> There's a heck of a lot of middle ground between "Fort Knox" and >> "Hippy Commune". > > We are not a hippy comune, just two married people, but I like to hear music > from my wife's home, and she uses to see documents that are on my home, so the > actual default fits quite well for 90% of computers out there: home computers. IIRC many weren't that happy with Windows 9x not supporting access control. I guess times have changed. > Think too on fathers accessing their minor child homes, offices in which > documents are property of the bussiness and not of any worker, etc. What about a minor child downloading a trojan (for whatever reason) which accesses the fathers home? A bug in a web scripts leading to www-data being compromised, and thus having read access to /home? -- Olaf -- 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/AANLkTimFfQ=1rk5_dfsbwe4addrf+guzucgg3dius...@mail.gmail.com
Re: RFC: bringing back task packages
[Not sure whether we should keep the long To: - list, I'd suggest continuing on debian-devel but keep it for the moment.] On Thu, Feb 17, 2011 at 07:20:30PM -0400, Joey Hess wrote: > A long time ago, tasksel installed task packages, which were regular > metapackages. This was dropped because the task packages had to Depend > on many packages, which made the installed system brittle, and made > testing propigation a problem. Now that Recommends are installed by > default, I'm revisiting the idea of using task packages. It solves > many issues and inconsistencies with tasksel vs the rest of Debian. If I understand the consequences of the statement correctly I welcome this step very much. > ### blends > > I think there is interest in getting some blends displayed in Taskel? Yes, definitely! > It's mostly orthagonal to this proposal, but this would help with > giving you full control over what your tasks do. I do feel that blends > need to be listed below the other tasks in tasksel, and probably with > a divider between them. This would be an acceptable approach. > Also, we have been careful to only have ten > tasks, to avoid overloading the user; and there is a limit to the length > of the list before it begins scrolling, so the d-i team would have to > look at the UI before adding Blends to the interface. The requirement for a limited set of tasks to provide a good overview is reasonable but has two flavours: On one hand it restricts the number of Blends we can include into the list and on the other hand it might have an influence on the number of "tasks"[1] we are maintaining inside each Blend which exceeds 10 drastically at least for three Blends (the most active ones). >From my perspective the only reasonable solution for this "reduced number of list entries" requirement is to close bug #273797 and have a hierarchical task selection where you first select the Blend and than select a set of "tasks"[1] inside the Blend. [1] Remark: I have the feeling that in the Blends context we are using the term "task" in some different manner. While it was probably influenced by tasksel (and invented by the Debian Edu developers) it drifted a bit away somehow. I have the feeling that we should find a proper definition what we mean when talking about Blends. > ## Implementation Option A > > Put everything in the task package. > > ... > > ## Implementation Option B > > Keep Test-*, Enhances, Relevance, and Section in the debian-tasks.desc > file; move the other fields to the task packages. I'm afraid I do not fully understand the difference / consequences of these two options. Can you provide some short examples? Kind regards Andreas. -- http://fam-tille.de -- 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/20110218134908.gh9...@an3as.eu
Re: Default Homedir Permissions
On Jueves 17 Febrero 2011 22:18:25 Ron Johnson escribió: > On 02/17/2011 08:58 AM, Roger Leigh wrote: > [snip] > > > Should it be locked down like Fort Knox? > > There's a heck of a lot of middle ground between "Fort Knox" and > "Hippy Commune". We are not a hippy comune, just two married people, but I like to hear music from my wife's home, and she uses to see documents that are on my home, so the actual default fits quite well for 90% of computers out there: home computers. Think too on fathers accessing their minor child homes, offices in which documents are property of the bussiness and not of any worker, etc. Just my (non DD) two cents Noel er Envite -- 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/201102181326.18332.env...@rolamasao.org
Re: how come the buildd machines can't find python-vtk?
* Steve M. Robbins , 2011-02-17, 21:27: I uploaded insighttoolkit the other day, but the buildd machines refuse to build it, claiming an installability problem [1]: insighttoolkit/alpha dependency installability problem: insighttoolkit (= 3.20.0-8) build-depends on one of: - python-vtk (= 5.4.2-8) I *think* the problem is that python-vtk is temporarily uninstallable due to the FFmpeg transition: http://lists.debian.org/debian-release/2011/02/msg00079.html -- Jakub Wilk -- 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/20110218102752.ga1...@jwilk.net
Re: What should we do with iceweasel/xulrunner/libmozjs?
Le vendredi 18 février 2011 à 13:34 +0100, Mike Hommey a écrit : > On Fri, Feb 18, 2011 at 12:59:46PM +0100, Josselin Mouette wrote: > > I’d favor that one too. The sooner we can adapt reverse dependencies to > > 4.0 in experimental, the better. And no need to do the work twice. > > There have been almost a year to adapt reverse dependencies to 3.6 in > experimental. And I don't think most rdeps are ready for 3.6. Do you > expect things to be significantly different? Yes. We’re no longer in a freeze but at the beginning of a development cycle. Note that we’re mostly doing the same for GNOME; skipping most of 2.32 in unstable, to work on 2.91 in experimental. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1298034464.18394.72.camel@meh
Re: squeeze-updates during Squeeze installation
> I also saw this error message but only under special circumstances. I > believe when I installed from a DVD and selected to not use a mirror. Yes, this is how to run into this error. > It's still somewhat disturbing. Maybe we should keep an empty "stable" > archive on volatile.debian.org in the mean time. Either that or how possible would to it be to make some kind of redirection? > I have just read a Debian 6 review[0] with the same (and other) > suggestion for improvement in the installer. Maybe someone wants to take > a look. > Hauke > [0] http://www.linuxbsdos.com/2011/02/14/debian-6-review/ I agree, changes could definitely be made on the installer. Adnan Adnan On Fri, Feb 18, 2011 at 7:30 AM, Raphael Hertzog wrote: > (Moving to debian-b...@lists.debian.org where it's more appropriate) > > On Fri, 18 Feb 2011, Adnan Hodzic wrote: >> Hello, >> >> During Squeeze installation process, since volatile archive was >> replaced with squeeze-updates and error of unreachable archive occurs. >> Of course installation process can be continued without any >> consequences, but I'm guessing installer should be updated so new >> users don't get confused with this error message. > > I also saw this error message but only under special circumstances. I > believe when I installed from a DVD and selected to not use a mirror. > > It's still somewhat disturbing. Maybe we should keep an empty "stable" > archive on volatile.debian.org in the mean time. > > Cheers, > -- > Raphaël Hertzog ◈ Debian Developer > > Follow my Debian News ▶ http://RaphaelHertzog.com (English) > ▶ http://RaphaelHertzog.fr (Français) > -- 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/aanlktindykmk_m5ariungj-vsataxyqc_dpkv6q0j...@mail.gmail.com
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 12:59:46PM +0100, Josselin Mouette wrote: > Le vendredi 18 février 2011 à 10:29 +0100, Benjamin Drung a écrit : > > I favor a combination of idea one and two, which is: Keep 3.5 in > > unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to > > unstable when it's out. > > > > Then we have one big break and a tested 4.0 in unstable. > > I’d favor that one too. The sooner we can adapt reverse dependencies to > 4.0 in experimental, the better. And no need to do the work twice. There have been almost a year to adapt reverse dependencies to 3.6 in experimental. And I don't think most rdeps are ready for 3.6. Do you expect things to be significantly different? Mike -- 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/20110218123427.gb22...@glandium.org
Re: Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
Thanks for jumping on this ITP, I wanted to point you to this ITP yesteday but got distracted by other stuff. Seems you've noticed it anyway, which is cool! :-) On Fri, Feb 18, 2011 at 12:08:25 (CET), Uoti Urpala wrote: > Reinhard Tartler tauware.de> writes: >> Package: wnpp >> Severity: wishlist >> Owner: Reinhard Tartler tauware.de> >> >> * Package name: mplayer2 >> Version : 2.0beta1 >> Upstream Author : Uoti Urpala pp1.inet.fi> >> * URL : http://www.mplayer2.org/ >> * License : GPL >> Programming Lang: C >> Description : next generation movie player for Unix-like systems >> >>MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, >>QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files, >>supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It >>can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies. >> >>Another big feature of MPlayer is the wide range of supported output >>drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB, > >> The text above is copied from the existing mplayer package. It is > > The long description really needs a rewrite. Absolutely. Actually, this is also true for the package description of the existing 'mplayer' package. >> basically a well-known and quite popular fork of mplayer. TBH, I'm a bit >> unsure what to do with it. From the first look, it seems that mplayer2 >> is better suited for being included in a distro release, but not (yet) >> in its current form. Currently, it includes a copy of ffmpeg-mt, a > > I'm not sure if you've misunderstood something or just phrased things > inaccurately, but I think this description is at least misleading for > people who aren't already familiar with the setup. Thanks for your elaboration on the issue. For practical packaging issue, I think it makes most sense to just use the copy of ffmpeg-mt that is included in the mplayer2 tarball. This is what i've referred to with saying 'includes a copy of ffmpeg-mt'. > I think having a package using FFmpeg-mt available is good, as it's a > substantial performance improvement over anything available in Debian today. > However as above this isn't directly forced by MPlayer2 itself. Which has been requested several times now. Relevant reports include: http://bugs.debian.org/575600 http://launchpad.net/bugs/611851 -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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/8762sh35ff@faui44a.informatik.uni-erlangen.de
get BULK sms FREE trial
Hello, Now you can send=A0 SMS at as low as 2.4 paise per SMS (Bulk SMS, dynamic = SMS,=20 Future SMS, SMS API available). Open www.ms-sms.in and get FREE trial as = well=20 as technical support=2E 1000 SMS - Rs.50 (per SMS 5 paise, 30 days validity) 5000 SMS - Rs.225 (per SMS 4.5 paise, 60 days validity) 1 SMS - Rs.400 (per SMS 4 paise, 90 days validity) 5 SMS - Rs.1750 (per SMS 3.5 paise, 120 days validity) 10 SMS - Rs.3000 (per SMS 3 paise, 6 months validity) 20 SMS - Rs.4800 (per SMS 2.4 paise, 1 year validity) Regards, Ripan www.ms-sms.in
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 10:12:42AM +0100, Mike Hommey wrote: [iceweasel] > - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push > 4.0 to unstable when it's out. Extra effort for you. > - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental > when it's released. > Cons: We lose version 3.6, which has several advantages over 3.5, and > keep 3.5, which is already very outdated. Well, but is there any point in sinking work into it? It's not like it's going last more than a couple of months. Any work you put into 3.6 reduces the polish on 4.0 by that much. Porting rdeps to 3.6 then to 4.0 would put additional strain on their respective maintainers, too. 4.0->experimental now and ->unstable when it's released would minimize the amount of unnecessary work, while giving 4.0 more exposure. It is stable enough for daily use, too. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20110218115957.gb16...@angband.pl
Re: What should we do with iceweasel/xulrunner/libmozjs?
Le vendredi 18 février 2011 à 10:29 +0100, Benjamin Drung a écrit : > I favor a combination of idea one and two, which is: Keep 3.5 in > unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to > unstable when it's out. > > Then we have one big break and a tested 4.0 in unstable. I’d favor that one too. The sooner we can adapt reverse dependencies to 4.0 in experimental, the better. And no need to do the work twice. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1298030386.18394.65.camel@meh
Re: What should we do with iceweasel/xulrunner/libmozjs?
Hi, Mike Hommey wrote: > - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push > 4.0 to unstable when it's out. That would be my favourite. I use Conkeror (which is a XULRunner application and hence depends on xulrunner) with 3.6 since it is in experimental and it works without problems since a year or so. Ubuntu has the Debian package with just slight modification of some defaults together with xulrunner-1.9.2 in Lucid 10.04 LTS. They just had to backport a few upstream fixes. OTOH since my upstream announced 4.0 compatibility a lot has changed in 4.0 (sic!) and the last time I tried it, it seemed to make quite some problems. Will check again the current state of the packages in the mozilla.d.n repo (and later experimental). > Cons: More work for reverse dependencies, which would be made to build > and work with 3.6 and then again with 4.0 in a few weeks. No problem for me. In the contrary, I'd be glad if 4.0 doesn't hit unstable immediately. > - Keep things the way they are (3.5 in unstable, 3.6 in experimental, > 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's > released. [...] > - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental > when it's released. I think 3.6 should go to unstable and replace 3.5 as soon as poosible, so these options look like heading backwards. > Cons: We lose version 3.6, which has several advantages over 3.5, and > keep 3.5, which is already very outdated. Right. That's why I want to see 3.6 in unstable as soon as possible independently of the state of 4.0. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20110218114159.gx12...@sym.noone.org
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Fri, Feb 18, 2011 at 10:12:42AM +0100, Mike Hommey wrote: > As I mentioned above, my initial idea was to go with the second option, > breaking most rdeps in the process, but then I remembered that 4.0 > doesn't work on all our architectures, and I'm hesitating, now. > > So, fellow developers, what do you think? To add some more insight, here is a list of the reverse build dependencies in main for xulrunner-dev: chmsee eclipse firegpg galeon gecko-mediaplayer gjs gluezilla gnome-chemistry-utils gnome-python-extras google-gadgets gtk-vnc instantbird kazehakase libgtk2-mozembed-perl libjdic-java libreoffice mongodb moon mozvoikko mozzemberek openjdk-6 openvrml packagekit parole pcmanx-gtk2 pyxpcom rhythmbox ruby-gnome2 sugar-hulahop swt-gtk totem virt-viewer vlc weave xiphos and for libmozjs-dev: couchdb edbrowse elinks freej gjs gxine libjavascript-perl libproxy mediatomb openvrml All these packages most probably need changes to at least build against 3.6 or 4.0. (though I wouldn't mind if someone would actually try ;) ) Mike -- 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/20110218113636.ga21...@glandium.org
Re: Bug#613806: ITP: mplayer2 -- next generation movie player for Unix-like systems
Reinhard Tartler tauware.de> writes: > Package: wnpp > Severity: wishlist > Owner: Reinhard Tartler tauware.de> > > * Package name: mplayer2 > Version : 2.0beta1 > Upstream Author : Uoti Urpala pp1.inet.fi> > * URL : http://www.mplayer2.org/ > * License : GPL > Programming Lang: C > Description : next generation movie player for Unix-like systems > >MPlayer plays most MPEG, VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, >QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA files, >supported by many native, XAnim, RealPlayer, and Win32 DLL codecs. It >can also play VideoCD, SVCD, DVD, 3ivx, RealMedia, and DivX movies. > >Another big feature of MPlayer is the wide range of supported output >drivers. It works with X11, Xv, DGA, OpenGL, SVGAlib, fbdev, DirectFB, > The text above is copied from the existing mplayer package. It is The long description really needs a rewrite. > basically a well-known and quite popular fork of mplayer. TBH, I'm a bit > unsure what to do with it. From the first look, it seems that mplayer2 > is better suited for being included in a distro release, but not (yet) > in its current form. Currently, it includes a copy of ffmpeg-mt, a I'm not sure if you've misunderstood something or just phrased things inaccurately, but I think this description is at least misleading for people who aren't already familiar with the setup. The player itself does not include a copy of any FFmpeg version, and can be compiled against any external library versions. However, using FFmpeg-mt is the best choice for the majority of users. Since there aren't packaged versions available for most distros (and it's not really suited for a systemwide install in its current form due to some API issues), the alternative recommended for most users is to statically link against a custom-compiled FFmpeg-mt. The build wrapper exists to make it easy to do this without needing separate manual library building steps. However, use of the wrapper is in no way forced, and users/packagers are free to choose what form of FFmpeg libraries to compile against. > well-known fork of the ffmpeg package, which features multithreaded h264 > decoding and actually is already in debian as part of the > chromium-browser package. While ffmpeg-mt is currently being > integrated/merged into ffmpeg upstream, mplayer2's future is not that > certain. If by future you mean the possibility of a merge with MPlayer 1, I think it's pretty certain that won't happen. It's possible that at some point MPlayer 1 will die and be completely replaced by MPlayer2, but any other kind of "merge" seems unlikely. > Having this in mind, I intend to maintain the package under the > pkg-multimedia umbrella. mplayer2 shoudl go to experimental for now, > including ffmpeg-mt. Help and ideas with that is more than welcome! I think having a package using FFmpeg-mt available is good, as it's a substantial performance improvement over anything available in Debian today. However as above this isn't directly forced by MPlayer2 itself. -- 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/loom.20110218t111649-...@post.gmane.org
Re: RFC: bringing back task packages
Hi, On Freitag, 18. Februar 2011, Charles Plessy wrote: > it would be very exciting to have the possibility to select a blend at the > installation. To circumvent the limitation of space, how about having a > single line to select ‘Chose a Debian Pure Blend‘, that would lead to a > page that provides the full list of blends ? and then probably a sub page again, ie Debian Edu has 6 different profiles to install (which can be combined just like tasks). cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: What should we do with iceweasel/xulrunner/libmozjs?
On Feb 18, Mike Hommey wrote: > - Suggest your own if you have better ideas (really, I mean it). I support option #2: I have been using it since you started packaging it and it works great: better than 3.6 and hugely better than 3.5. s390, sparc and ia64 are not exactly popular architectures, and more so on desktops, so I believe that encouraging their porters would be helpful. -- ciao, Marco signature.asc Description: Digital signature
Re: chromium-browser is taking over all URLs
Am Freitag, den 11.02.2011, 17:11 +0100 schrieb Leo "costela" Antunes: > On 11/02/11 16:49, Norbert Preining wrote: > > On Fr, 11 Feb 2011, Cyril Brulebois wrote: > >> $ grep x-scheme-handler/http /usr/share/applications/mimeinfo.cache > >> x-scheme-handler/http=midori.desktop;chromium-browser.desktop; > >> x-scheme-handler/https=midori.desktop;chromium-browser.desktop; > >> > >> And it takes precedence over what you quoted. > > > > Thanks a lot!!! > > > > Ahhh, and how does one fix that? This is misbehaviour. Whom should > > this bug reported to? mime or chromium? > > I noticed the same issue here a few days ago. > Adding the "x-scheme-handler/http;x-scheme-handler/https;" entries to > iceweasel.desktop doesn't really solve the issue, because there doesn't > seem to be a mechanism to define priorities in update-desktop-database, > so gvfs-open uses the first entry in mimeinfo.cache. You can put: > [Added Associations] > x-scheme-handler/http=iceweasel.desktop; > x-scheme-handler/https=iceweasel.desktop; into $HOME/.local/share/applications/mimeapps.list. Regards, Daniel -- 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/1298025624.4658.10.ca...@haktar.wgdd.de
Re: how come the buildd machines can't find python-vtk?
On Thu, Feb 17, 2011 at 21:27:16 -0600, Steve M. Robbins wrote: > I uploaded insighttoolkit the other day, but the buildd machines > refuse to build it, claiming an installability problem [1]: > > insighttoolkit/alpha dependency installability problem: > > insighttoolkit (= 3.20.0-8) build-depends on one of: > - python-vtk (= 5.4.2-8) > > This is repeated for all architectures. > > Two things puzzle me: > > 1. python-vtk is still in the archive according to the PTS >and "rmadison" > > 2. the above output says "(= 5.4.2-8)", but the build-dep isn't >versioned > > What's going on? > http://edos.debian.net/edos-debcheck/results/unstable/1298005520/i386/list.php#python-vtk python-vtk is involved in the ffmpeg transition, and needs to be rebuilt. In the mean time, it's not installable, so insighttoolkit can't be built. Cheers, Julien -- 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/20110218095849.gf12...@radis.liafa.jussieu.fr
Re: RFC: bringing back task packages
On Fri, Feb 18, 2011 at 10:39:16AM +0900, Charles Plessy wrote: > > ### i18n > > > > There are many language tasks in tasksel. It might be good to have > > the task packages be moved out of tasksel; I don't know if it'd make > > sense to have individual language teams maintain them, or what. > > On the other hand, I would warmly welcome an i18n task that reproduces the > user > experience on Macintoshes, where a standard system contains everything to read > and write a large number of languages. Currently with Debian, on fresh > installs, I have to iterate over the missing fonts for Japanese and other > Asian > languanges, A meta-package that installs fonts that provide a glyph for every code point in Unicode would be great. Preferably something better than ttf-unifont that supports only Plane 0 and is butt-ugly. If you do anything related to i18n, having fonts that at least resemble what would be used by users is a must. > and look back on my old notes to figure out what packages will > provide me an input system for chinese characters, because I select French or > English at install time. On the contrary, I don't see what an input system would be good for. How many languages can you write? I can do a few languages with the Latin script and some basics of Cyrillic -- but even that with a phonetic keymap, stretching my remnants of Russian lessons from the elementary school. Such a task would be useful only for installs that are meant to cater to many users from all around the world -- a very rare occurence, while cluttering and potentially slowing down the systems of everyone else. I do believe that every developer who does something even remotely related to displaying text that might possibly behave different for double-wide, combining, etc, characters (including for example every single curses program), has a duty to at least briefly check if these work correctly. However, for input, unless you do something low level, pasting text works just as well and is so much simpler if you don't know the script in question. Having two such tasks in tasksel would be needless clutter, but at least on metapackage level, let's have output and input separated. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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/20110218095105.ga16...@angband.pl
Re: What should we do with iceweasel/xulrunner/libmozjs?
Am Freitag, den 18.02.2011, 10:12 +0100 schrieb Mike Hommey: > Hi, > > Now that squeeze is released, it's time to start pushing new things to > unstable. I've been asked several times already how things would be > evolving in the near future, to which I answered it would quite stay the > way it is now until upstream releases 4.0, at which point I'd upload 4.0 > to unstable. But that might change. And I'm hereby requesting feedback > on what fellow developers (especially maintainers of the various reverse > dependencies) think about them. > > Here are some of the available options: > > - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push > 4.0 to unstable when it's out. > Pros: More exposure for the 3.6 and 4.0 packages. > Cons: More work for reverse dependencies, which would be made to build > and work with 3.6 and then again with 4.0 in a few weeks. > Last time I checked (which was 3 months ago), 4.0 doesn't work > on s390, sparc and ia64, which would make problems. > > - Keep things the way they are (3.5 in unstable, 3.6 in experimental, > 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's > released. > Pros: we don't need to make sure everything in unstable builds and > works properly with 3.6 before doing the work again with 4.0 in a > month or so. > Cons: Broken architectures with 4.0. > > - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental > when it's released. > Pros: We don't break anything in testing/unstable, and we don't have > to deal immediately with the broken architectures. > Cons: We lose version 3.6, which has several advantages over 3.5, and > keep 3.5, which is already very outdated. > > - Keep everything in place, prepare rdeps to build and work with 4.0, > and push 4.0 to unstable when everything is ready. > Pros: We don't break anything in testing/unstable, and when 4.0 lands > on unstable, nothing breaks either. > Cons: Past experience shows that it takes a lot of time to fix rdeps. > My gut feeling is that breaking things in unstable would create an > incentive to fix, which doesn't exist when the package is in > experimental or worse, outside the archive. > > - Suggest your own if you have better ideas (really, I mean it). > > As I mentioned above, my initial idea was to go with the second option, > breaking most rdeps in the process, but then I remembered that 4.0 > doesn't work on all our architectures, and I'm hesitating, now. > > So, fellow developers, what do you think? I favor a combination of idea one and two, which is: Keep 3.5 in unstable and push the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Then we have one big break and a tested 4.0 in unstable. -- Benjamin Drung Debian & Ubuntu Developer signature.asc Description: This is a digitally signed message part
Re: squeeze-updates during Squeeze installation
Hi. Le vendredi 18 février 2011 à 08:30 +0100, Raphael Hertzog a écrit : > (Moving to debian-b...@lists.debian.org where it's more appropriate) > (Sorry about the noise, as I'm subscribed to that list, reponding to -devel too anyway). > On Fri, 18 Feb 2011, Adnan Hodzic wrote: > > Hello, > > > > During Squeeze installation process, since volatile archive was > > replaced with squeeze-updates and error of unreachable archive occurs. > > Of course installation process can be continued without any > > consequences, but I'm guessing installer should be updated so new > > users don't get confused with this error message. > > I also saw this error message but only under special circumstances. I > believe when I installed from a DVD and selected to not use a mirror. > > It's still somewhat disturbing. Maybe we should keep an empty "stable" > archive on volatile.debian.org in the mean time. I kind of remember having seen a prompt for volatile in the graphical installer, but noticed that there was squeeze-update in the sources.list at the end, somehow. Hope this helps. Best regards, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- 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/1298021090.4767.6.ca...@inf-8657.int-evry.fr
Re: squeeze-updates during Squeeze installation
On Fri, Feb 18, 2011 at 08:30:17AM +0100, Raphael Hertzog wrote: > (Moving to debian-b...@lists.debian.org where it's more appropriate) > > On Fri, 18 Feb 2011, Adnan Hodzic wrote: > > Hello, > > > > During Squeeze installation process, since volatile archive was > > replaced with squeeze-updates and error of unreachable archive occurs. > > Of course installation process can be continued without any > > consequences, but I'm guessing installer should be updated so new > > users don't get confused with this error message. > > I also saw this error message but only under special circumstances. I > believe when I installed from a DVD and selected to not use a mirror. > > It's still somewhat disturbing. Maybe we should keep an empty "stable" > archive on volatile.debian.org in the mean time. I have just read a Debian 6 review[0] with the same (and other) suggestion for improvement in the installer. Maybe someone wants to take a look. Hauke [0] http://www.linuxbsdos.com/2011/02/14/debian-6-review/ -- .''`. Jan Hauke Rahmwww.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org -- 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/20110218091040.ga3...@ca.home.jhr-online.de
What should we do with iceweasel/xulrunner/libmozjs?
Hi, Now that squeeze is released, it's time to start pushing new things to unstable. I've been asked several times already how things would be evolving in the near future, to which I answered it would quite stay the way it is now until upstream releases 4.0, at which point I'd upload 4.0 to unstable. But that might change. And I'm hereby requesting feedback on what fellow developers (especially maintainers of the various reverse dependencies) think about them. Here are some of the available options: - Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push 4.0 to unstable when it's out. Pros: More exposure for the 3.6 and 4.0 packages. Cons: More work for reverse dependencies, which would be made to build and work with 3.6 and then again with 4.0 in a few weeks. Last time I checked (which was 3 months ago), 4.0 doesn't work on s390, sparc and ia64, which would make problems. - Keep things the way they are (3.5 in unstable, 3.6 in experimental, 4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's released. Pros: we don't need to make sure everything in unstable builds and works properly with 3.6 before doing the work again with 4.0 in a month or so. Cons: Broken architectures with 4.0. - Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental when it's released. Pros: We don't break anything in testing/unstable, and we don't have to deal immediately with the broken architectures. Cons: We lose version 3.6, which has several advantages over 3.5, and keep 3.5, which is already very outdated. - Keep everything in place, prepare rdeps to build and work with 4.0, and push 4.0 to unstable when everything is ready. Pros: We don't break anything in testing/unstable, and when 4.0 lands on unstable, nothing breaks either. Cons: Past experience shows that it takes a lot of time to fix rdeps. My gut feeling is that breaking things in unstable would create an incentive to fix, which doesn't exist when the package is in experimental or worse, outside the archive. - Suggest your own if you have better ideas (really, I mean it). As I mentioned above, my initial idea was to go with the second option, breaking most rdeps in the process, but then I remembered that 4.0 doesn't work on all our architectures, and I'm hesitating, now. So, fellow developers, what do you think? Mike -- 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/20110218091242.ga4...@glandium.org
Re: RFC: bringing back task packages
Le jeudi 17 février 2011 à 19:20 -0400, Joey Hess a écrit :
> ### gnome
>
> Would the gnome team want to maintain a task-gnome?
> Much of tasksel's gnome task is already taken from the gnome-core
> and gnome metapackages, with a few more things added.
Yes, they fit globally the same purpose. There are just some small hacks
to handle tasksel; for example we allow OOo as an alternative to
gnome-office to avoid installing both by default when OOo was already
selected by the desktop task. I don’t think anything needs to change on
that matter.
> task-gnome
> would not need to deal with core X desktop stuff; task-desktop would
> still handle that. Although we could move away from having a task-desktop
> if you'd prefer.
I’d prefer to keep it separate. The gnome metapackage should be
installable on a session server without any X server installed.
> There are also many localized desktop tasks. Mostly these add things
> like localization packages for openoffice, and occasionally some fonts.
> I'd like to see those be maintained in conjunction with task-gnome,
> but it would mean some coordination with the dozens of people who
> currently maintain those localization tasks.
I’m afraid the approach of using tasks for localization does not scale.
Instead, I’d like to see introduced something like conditional
recommends: that is, recommends that would only be installed if a
third-party package if already here (and that would get installed when
installing the said third-party package).
This way, you could do in all packages something like:
Package: aspell
Conditional-Recommends: aspell-en {task-english}, aspell-fr
{task-french}, …
This would also be useful for some plugins. I don’t know how hard this
would be to implement in APT.
> Packages -> Recommends
> Recommends may be better than what we have now in tasksel.
> If aptitude auto-selects *new* recommends of a previously installed
> package to be installed? Currently new Packages added to a task
> only affect new installations of that task.
AFAIK new Recommends are not installed. That is the reason why we still
heavily use Depends in metapackages instead.
Cheers,
--
.''`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.”
`--- J???rg Schilling
--
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/1298020358.18394.59.camel@meh
Re: [Adduser-devel] Default Homedir Permissions
This one time, at band camp, Ian Jackson said:
> [Someone] writes ("Re: Default Homedir Permissions"):
> > [stuff]
>
> We are in danger of wasting a lot of time with this discussion.
>
> The general pattern is that someone who is unhappy with the state of
> the world proposes a substantial change. The worry amongst the rest
> of us is that the change might go ahead if we don't oppose it.
>
> So those of us who oppose feel impelled to respond to every message;
> whereas the proponent of change is dedicated. There is no natural
> conclusion to this argument.
>
> So I would like the maintainers of the adduser package (which seems to
> be where the default is mainlys et) to post here to reassure us that
> they don't intend to make this change, and that if the maintainers are
> thinking of changing their mind they will consult debian-devel.
I don't want to prolong this thread, but this seemed useful to answer.
I certainly have no intention of changing the default on my own.
My hope is that Debian is used in ways I can't imagine, and I can not
begin to cater to all of the variety of needs that current and future
users will want. I think that 0755 as a default plus the ability to
alter adduser.conf is enough flexibility to allow admins to create users
as they see fit, while still catering to the most common case out of the
box. No matter what we pick, someone will be unhappy.
I'd be quite happy to take this up with the tech ctte if Olaf disagrees
strongly enough.
Cheers,
--
-
| ,''`.Stephen Gran |
| : :' :sg...@debian.org |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Re: RFC: bringing back task packages
Quoting Joey Hess (jo...@debian.org): > ### i18n > > There are many language tasks in tasksel. It might be good to have > the task packages be moved out of tasksel; I don't know if it'd make > sense to have individual language teams maintain them, or what. Many teams are definitely too small to do that (often one individual and often someone not that deeply involved in Debian), so except for a few "real" teams, it would probably make better sense to have i18n (indeed often l10n) tasks maintained by the whole i18n crowd. signature.asc Description: Digital signature
