Re: software updates file in /usr -- policy bug?
On Mon, Oct 25, 2004 at 07:11:45PM +0200, martin f krafft wrote: > Hi all, > > apt-spy and pciutils (and possibly others) contain methods to update > a database integral to their operation. > > - `apt-spy update` downloads the list of available Debian mirrors > to /usr/share/apt-spy (see #277816). > > - `update-pciids` downloads a new /usr/share/misc/pci.ids > > I think these are both in violation with the FHS, which states > (Chapter 4, emphasis mine, using caps instead of asterisks for > readability): > > "/usr is shareable, READ-ONLY DATA. That means that /usr should be > shareable between various FHS-compliant hosts and MUST NOT BE > WRITTEN TO." dpkg should not put files in /usr when it extracts programs either if /usr MUST NOT BE WRITTEN TO... ;) Chris
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Why doesn't dpkg use the -a flag to diff? Chris
Re: Which 2.6 kernel for Sarge on a Via C3?
On Wed, Nov 10, 2004 at 07:33:43PM +0100, Jerome Warnier wrote: > I'm wondering why I can't see many different 2.6 kernels on my Sarge > systems any longer. I own a Via C3-based computer (an x86 for those who > didn't know) and can find only -386 and -686 kernels which could > possibly match. > > Somebody knows? I seem to recall the C3 is missing the CMOV instruction which would require that you use a kernel < i686, so in this case the i386 kernel. Chris
Re: MPEG in general Was: Is anyone packaging `lame' ?
On Fri, Jan 07, 2005 at 11:32:45PM +0100, xerces8 wrote: > Hi! > > ( sorry for not properly replying, I'm using a webmail ) > > Is only MPEG Layer III patent encumbered ? > How about the other MPEG stuff ? > I find it hard to believe that it is all patent-free. > > Regards, > David Balazic Its all encumbered, there is a separate organization MPEG-LA that strictly deals with the licensing. It is quite surprising to me that ffmpeg was allowed into main. Chris
Re: list what's in the NEW queue?
On Fri, Feb 04, 2005 at 01:14:09PM +, Brian M. Carlson wrote: > I think this is an awful idea. This means that developers will no longer > test their packages before uploading, and we will have more bugs than > before. Why build X [0] when you don't "have to"? > > [0] No attack on Branden, but it's the largest package I could think > of. You already don't have to build any arch packages, just indep. Its just not widely publicized that it works, oops now it is. ;) I don't know if it was ever actually technically required that you upload arch packages. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MPEG in general Was: Is anyone packaging `lame' ?
On Mon, Jan 10, 2005 at 11:55:30PM +0100, Tollef Fog Heen wrote: > * Chris Cheney > > | Its all encumbered, there is a separate organization MPEG-LA that > | strictly deals with the licensing. It is quite surprising to me that > | ffmpeg was allowed into main. > > According to rumors I heard, it was allowed in since other > applications (xine at least, I think) already included it. So it > didn't really make a difference -- if we're infringing on patents with > ffmpeg, we are with xine as well. > > (Apologies if xine is not the package I'm thinking about.) Wouldn't that be an argument to have xine removed from Debian not the addition of ffmpeg? Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL support in 2.4 kernel series?
On Sat, Jan 22, 2005 at 07:53:19PM +0200, Fabian Fagerholm wrote: > For another perspective, think about the ongoing work to support other > kernels than Linux. Presently, promising work is apparently being done > on both Debian GNU/Hurd and Debian GNU/FreeBSD kernels. There are > already packages that are Linux-kernel-specific and they will need > support in the package management system to depend on > "kernel-image-linux" or something more specific like > "kernel-image-linux-2.6". (One may assume that "kernel-image", > representing any kernel, is an essential package, always installed.) So > it's not just about different versions of Linux, it's about different > kernels altogether. And there should be a way to specify such > dependencies on the package management system level. Those other kernels dpkg arch aren't "i386", they will be one of the following: darwin-i386 freebsd-i386 hurd-i386 kfreebsd-i386 netbsd-i386 knetbsd-i386 openbsd-i386 So they don't need depends on a kernel either, they just need their arch line to be set for the proper archs they support. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: pptpd
I am appling to become a new maintainer. I am intending to package pptpd which is the point to point tunneling protocol daemon. Chris Cheney Please cc: me in any replies.
GNOME package versions
I took a few minutes to check what versions of gnome packages were in potato and in /incoming to compare against the current gnome ftp site. The first column shows the version in debian and the filename is the version on the ftp site. *** means it does not appear to be packaged yet. -Chris PS - Thanks to all who are updating the packages :) *** 541066 Aug 2 17:32 Gtk---1.0.2.tar.gz 0.4.95 981072 Sep 27 15:46 ORBit-0.4.96.tar.gz 1.0.5 1136447 Sep 20 22:41 control-center-1.0.40.tar.gz 0.3.9 385472 Aug 30 19:44 ee-0.3.10.tar.gz 0.2.10 244873 Sep 16 16:56 esound-0.2.14.tar.gz 0.4.1 1166853 Sep 24 16:56 glade-0.5.3.tar.gz 1.0.2 3543133 Sep 24 11:21 gnome-games-1.0.40.tar.gz 1.0.40 3196381 Sep 27 15:19 gnome-libs-1.0.42.tar.gz *** 313788 Sep 20 17:58 gnome-objc-1.0.40.tar.gz 0.5 638350 Sep 21 16:12 gtk-engines-0.7.tar.gz 1.0.2 370197 Sep 24 01:27 gtop-1.0.4.tar.gz *** 101650 Aug 25 16:52 java-gnome-0.3.tar.gz 0.4 310798 Sep 19 23:10 libglade-0.6.tar.gz 1.0.1 712283 Sep 24 01:26 libgtop-1.0.4.tar.gz 1.4.0 729312 Sep 26 06:40 libxml-1.7.2.tar.gz pgpUvsef5u8ug.pgp Description: PGP signature
Re: GNOME package versions
> Chris Cheney <[EMAIL PROTECTED]> writes: > Well, no, it just means you're not aware of Debian's naming schemes > for library packages. > > > *** 541066 Aug 2 17:32 Gtk---1.0.2.tar.gz > > look for *gtkmm Ok I see it now. :) > > *** 313788 Sep 20 17:58 gnome-objc-1.0.40.tar.gz > > libgnobjc or something to that effect. I still don't see this package anywhere, I am either overlooking it or it is not packaged? Thanks, Chris pgpBage1zJ2Jp.pgp Description: PGP signature
NcFTP is free again?
I just looked at NcFTP 3.0Beta20 and it appears to have changed its license to free (no license file) and the libncftp requirement of non-use by other programs seems to have been dropped also. Maybe someone more knowledgeable than me can look at this and see if it can be packaged again. Thanks, Chris pgplbAlGZ2jfj.pgp Description: PGP signature
Re: Debian menu system update
Is the Debian menu system going to convert to using the freedesktop menu spec? http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html As far as I know both Gnome and KDE follow it and possibly others. Chris
Re: Debian menu system update
On Thu, May 29, 2003 at 01:12:08PM -0500, Gunnar Wolf wrote: > I am not too sure I want this... One of the great things about our menu > system is that it complies with a rather logical policy - menus are not > overly nested. I don't know how is the .desktop format, but I understand > it is just that - a format. I really doubt it provides the coherency of > Debian's menu system - Imagine, for example, a developer files his > browser in Apps/Browsers instead of Apps/Net - What can we do about it? > We can not even file a bug. He will probably not care about our > complaint, as he does not need to abide by any policy for HIS work. This is not a problem. (See below) > Menu systems, IMHO, are the task of a distribution - a way to organize a > collection of software. They should not be the task of individual > developers. If this were slashdot I would probably let it slide. You obviously did not even look at the desktop menu spec or desktop entry spec. Read the following sections before further commenting... http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#DESKTOP-ENTRY-EXTENSIONS http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#CATEGORY-REGISTRY http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#ONLYSHOWIN-REGISTRY http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#THIRD-PARTY-HOWTO Also notice who wrote the spec... Maintaining our own menu entries is a great disservice to users as well, or do you have a plan on how to do i18n for all the languages that works as well as the GNOME and KDE groups? KDE supports over 60 now, I am not certain about GNOME. Pushing desktop entries to upstream of packages allows everyone to benefit from translations and from the menu support itself. Thanks, Chris
Re: Debian menu system update
On Thu, May 29, 2003 at 04:16:38PM -0400, Colin Walters wrote: > On Thu, 2003-05-29 at 14:12, Gunnar Wolf wrote: > > - Imagine, for example, a developer files his > > browser in Apps/Browsers instead of Apps/Net - What can we do about it? > > Um, patch it, just like we do for other upstream things we want to > change? Alternatively we can override it using a Menu file, once we > have the Desktop Menu Specification implemented. This isn't even an issue since desktop files use categories not hardcoded locations like that. Its up to the menu system to use the categories as it sees fit (at least aiui). Chris
Re: Debian menu system update
On Fri, May 30, 2003 at 11:19:44AM +0200, Bernhard R. Link wrote: > * Colin Walters <[EMAIL PROTECTED]> [030529 22:40]: > > Yes, it is our task to make it *consistent*. It shouldn't be our task > > to write menu entries from scratch, when upstreams can (and are) taking > > on the task. Our menu system should accept .desktop files, and ideally > > process them natively. > > I think making things consistent needs us to write them on our own, > taking upstream entries as suggestions. In my eyes it is just the same > as with the directories software is installed into. There are just too > many ways to do it and we do not serve our users well to let them all in. I'll let you learn all the languages of the world so that we can throw away upstreams fully i18n menu entries... > > Of course it would be nice to have things on places, where users know > them, but without an consistent concept overall, there is no use to it. > (Last time I looked we did not put KDE in /opt, though that might have > things much easier and I'm sure many people were expecting it there...) Its Debian that is being inconsistent... > > The next step is to migrate to the Desktop Menu Specification. This is > > still in the process of being adopted by GNOME and KDE. We will need to > > rewrite our menu-methods to process the .menu files. > > The menu-methods are there to generate the menus for the menu-providers, > to parse whatever format is the menu-entries is update-menus' task. > It would be nice to make menu-methods to generate .menu files easier. > I think making update-menus able to parse files in dektop menu > specification will only cause such files beeing included without > inspection by newbies. I do not understand this statement. Why would newbies inspect desktop entries to begin with... > > After that, our user experience with popular desktops should be much > > more consistent, > > As adminstrator of some systems with many users, I'd prefer if this > broken KDE could at least be packaged with hints how to get rid of > its broken menu and a debian menu pluged in instead. (I've long given > up hope to get a useful menu in it by default, I know its KDEs > philosophie to not integrate but creating a world of its own. But at > least the debian packages could provide some information how to get > some minimal usability in it). It is Debian that is broken since it does not follow the desktop menu specification. Both GNOME and KDE follow it and will soon have integrated menus, only Debian stuff will then be outside of the menu. >From the desktop spec it appears that both XFCE and ROX support it as well but I haven't run them before. > > and it will be less work to integrate new software into > > Debian (since upstreams will be adopting .desktop), > > There a many things, that make proper packaging of software a > complex matter. Writing this single line to get a menu-item > should really no problem. And if it was I really doubt the > person involved was competent enough to look in the .desktop-file > if it is reasonable... Now it becomes obvious you did not look at any .desktop files either... slashdot is dooming us all. A single Debian Developer _CAN NOT_ write decent menu entries _period_. See the attached konqueror desktop file, notice it has translations for 57 languages. Also notice Debian does good to get translations for debconf entries for more than 1 language, and thats only after someone decides to submit bug reports (in other words takes a long time). > > and other > > distributors will benefit from the .desktop files Debian developers > > write. > > This makes a shoe out if it. Debian is *much* more than KDE and GNOME, > using .dektop will in the long run cause masses of people learn a new > format and in order to get a coherent understandable system need rewrite > of masses of old Debian people SHOULD NOT be writing the menu entries. And it is trivial to learn if a DD does want to submit a skeleton one to their upstream. As I already said above a menu entry written by only one person is of little value since it will have no or very little i18n support. > > A Debian-specific menu system is the entirely wrong way to go. > > A working menu is a good way to go. The currest system works and has > many nice aspects of configurability and administrability, missing in > the newer parts. Only thing I see missing are KDE packages obeying > menu policy. The current system is limping along and needs to be shot. KDE obeys menu policy just fine (afaik) it has stupid i18n-less debian menu entries but when used in KDE itself it uses its fully i18n'd .desktop files just like GNOME. Chris PS - Next time try to learn about a system before showing you don't understand the issues at all. [Desktop Entry] Encoding=UTF-8 Type=Application Exec=kfmclient openProfile webbrowsing Icon=konqueror DocPath=konqueror/index.html Name=Konqueror Web Browser Name[af]=Konqueror Web Blaaier Name[az]=Konqueror Veb Səyyahı Name[b
Re: Debian menu system update
On Fri, May 30, 2003 at 09:59:57AM +0200, Morten Brix Pedersen wrote: > In implementing it, I have encountered some issues which I would appreciate > input on. > > 1) The sections that are normally used within the Category field in a .desktop > file isn't the same as with menu. Here I have decided to make menu > automatically convert a category into menus system. E.g. Category: > Application;WordProcessor will be changed to Apps/Editors. Aiui Category can contain any number of tags in any order so you may want to keep that in mind (if you didn't think about it yet). > 2) The current menu files use a "needs" field to designate whether the > application uses console or X11 (e.g. needs="text"). In our .desktop > files, this field will be named X-Menu-Needs and will only be required > for non-X11 applications. (so current GNOME/KDE .desktop entries won't > have to be changed) This can't be translated simply as "ConsoleOnly"? As below: Categories: ConsoleOnly - Application that only works inside a terminal (text-based or command line application). There is also a "Shell" category for shells such as bash. http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html#CATEGORY-REGISTRY > 3) The current menu files has a "package" field to designate which > package must be installed before the menu file will be used. In our > .desktop files, this field will be named X-Menu-Package. But I'm unsure > whether we should still require this field. Not requiring it might break > some menu entries; but requiring it will force us to change upstreams > .desktop files with the addition of X-Menu-Package. What actual cases is this field used in? I don't think I recall seeing it used before. Shouldn't the menu entry exist in the package it must have installed (I suppose I could be missing something). Also we probably should prefix Debian specific desktop files to avoid namespace collisions (like debian-foo.desktop) as the desktop spec mentions. Chris
Re: Debian menu system update
On Sun, Jun 01, 2003 at 08:59:58PM +0200, Josef Spillner wrote: > One day, SVG icons might be used, so there has to be some kind of flexibility. > It would be nice to work towards collaboration with freedesktop.org, probably > a fallback mechanism can be implemented. > I personally do not want to restrict myself to 214 ugly colours, and others do > not want to use scalable icons. With only one of both implementations, it > will never be possible to make everyone happy. SVG icons are the only decent long term solution once screens go to 200dpi+ those tiny icons will be worthless, of course you can always double or triple the size of fixed size icons automatically but they won't look very good. Microsoft is pushing for high resolution screens to be available in time for its new OS 'Longhorn' release, which is only around 2 years from now. Chris
Re: Debian menu system update
On Sun, Jun 01, 2003 at 04:34:55PM +0200, Bernhard R. Link wrote: > * Chris Cheney <[EMAIL PROTECTED]> [030530 20:50]: > > > I think making things consistent needs us to write them on our own, > > > taking upstream entries as suggestions. In my eyes it is just the same > > > as with the directories software is installed into. There are just too > > > many ways to do it and we do not serve our users well to let them all in. > > > > I'll let you learn all the languages of the world so that we can throw > > away upstreams fully i18n menu entries... > > I'm nor talking about throwing them away in general. I'm talking about a > consistent menu. If all your menu shall contain are KDE-programs, you > might archieve this by blidly copying upstream items. Any application that is written for GNOME or KDE (KDE 3.2+) will be in the same menu. As I undestand it both ROX and XFCE menus work the same way as well. > > > Of course it would be nice to have things on places, where users know > > > them, but without an consistent concept overall, there is no use to it. > > > (Last time I looked we did not put KDE in /opt, though that might have > > > things much easier and I'm sure many people were expecting it there...) > > > > Its Debian that is being inconsistent... > > Debian may be inconsistent with other distributions. But within Debian > it's a dream of consistency. I have users using fvwm, wmaker, qvwm, > icewm and others. And all have exactly the same menu. All can look at > the others screen to show each other where to find the program to use. > > The only thing inconsistent in this regard are KDE-packages, which just > have a unbearable menu. But I guess I'm just not in favor of KDEs > philosophie. I never found a way to let KDE users look at .ps files > other than ininstalling kghostview... Right clicking on the file in konqueror and telling it to open with some other app doesn't work? (Works fine for me) I am viewing a pdf file in xpdf right now. If you want to make it permanent just click on edit file type instead and change the default. Or run kcontrol -> KDE Components -> File Associations to change them. By the way mime types are also defined using desktop files and there is a specification for how that should work on freedesktop.org as well. After the Debian menu system has been ported to using desktop files the mime system will probably be the next thing on the list. > > > I think making update-menus able to parse files in dektop menu > > > specification will only cause such files beeing included without > > > inspection by newbies. > > > > I do not understand this statement. Why would newbies inspect desktop > > entries to begin with... > > I was talking about DD newbies. >From your posts to me and others it seems you are a Linux newbie as well. Perhaps you need to learn more before posting about topics you don't fully understand. > > It is Debian that is broken since it does not follow the desktop menu > > specification. Both GNOME and KDE follow it and will soon have > > integrated menus, only Debian stuff will then be outside of the menu. > > I'd really be suprised, if those will become so simmilar. Even the > update-menus rewrite to parse the new format seems not to aim at > having all wms in debian exactly the same menu. They aren't going to become so similiar... they already are the same. As soon as KDE 3.2, which is currently in development, is released they will be combined in Debian. People running the KDE 3.2 cvs debs already benefit from this merge. By the way there are already 423 desktop files in Debian. > > > There a many things, that make proper packaging of software a > > > complex matter. Writing this single line to get a menu-item > > > should really no problem. And if it was I really doubt the > > > person involved was competent enough to look in the .desktop-file > > > if it is reasonable... > > > > Now it becomes obvious you did not look at any .desktop files either... > > slashdot is dooming us all. A single Debian Developer _CAN NOT_ write > > decent menu entries _period_. See the attached konqueror desktop file, > > notice it has translations for 57 languages. > > If there is a proper wording for a menu-item upstream (Note that the > item and its place in menu are two different things), then there is > no reason not to use it in the debian package. And then there is also > no problem to include all the translations. This is just extra effort that is not needed, and likely to get screwed up by inept developers munging utf8 characters. > > Debian people SHOULD NOT be writing
Re: ATI Linux Driver Packages
/me coughs ;)
Re: ATI Linux Driver Packages
Are these drivers much better then than XFree ones or is there a reason to be promoting nonfree drivers? I orginally packaged up the nvidia ones in the way they are done due to the fact the XFree ones had no 3d acceleration at all and that it was illegal to distribute nvidia's binaries directly. Also binary only drivers will taint the kernel and can cause the user to have trouble getting help with kernel related issues. I got rid of my nvidia cards (some poor sucker took them) and now use only ATI cards. 8) Chris
Re: ATI Linux Driver Packages
On Sun, Jun 01, 2003 at 11:16:12PM -0500, Adam Majer wrote: > I think you might be the "sucker". :) [ok, it's not a flame thing]. > Does the radeon driver support 3D accel for cards beyond the R1xx level? > ie. something like Radeon 7500. I don't think that Radeon 8500, 8800, etc..a > are supported since they use the former FireGL GPU. The drivers from > ATI fill the gap to support FireGL, and yes they are better. They > can be used with Maya etc.. [at least it says that on ATI's site.] As I understand it XFree86 4.3.0 supports 2D/3D for the following: rv100 - Radeon 7000 r100- Radeon 7200 rv200 - Radeon 7500 r200- Radeon 8500/Radeon 9100/FireGL 8700/FireGL 8800 rv250 - Radeon 9000 rv280 - Radeon 9200 XFree86 4.3.0 has 2D support for the following: r300- Radeon 9500/Radeon 9700 XFree86 4.3.0 doesn't support the following at all: rv350 - Radeon 9600 r350- Radeon 9800 It is bad news that ATI hasn't released the documentation for the R300/R350 chipsets yet. :< I hope they haven't decided to imitate nvidia now they finally have beaten them on windows benchmarks. If this is the case it needs to become more apparent to users that they are no longer the company to buy from to help support OSS friendly companies. > BUT, ATI doesn't have any drivers for new cards like Radeon 9800 and I > do not think they will have any Linux drivers. > > On the other hand, I installed Debian for a frried and he had a > GeForce 4 MX card. The driver from nVidia worked perfectly. > Futhermore, I think that they only distribute the X driver that's > precompiled. The kenrel part has to be compiled by hand (which is good). Nvidia's drivers have been notorious over the years at causing crashes. >From what I have heard recently this is still the case. If it doesn't crash for you then you are lucky. When I still had my nvidia card it crashed under any strain with the nvidia binary driver. > Futhermore, I believe that nVidia have _much_ better support in X > from nVidia than radeon ever had from ATI. The free 3D driver > hacked together does not give good performance as does nVidia's > propriatory driver. Frankly, I very much prefer that nVidia has > in-house support for their cards while ATI has none (the ones for > Radeon 8500, 8800, etc.. are just FireGL drivers). Don't forget that binary only drivers are likely to have rendering cheats such as the one found that nvidia did on 3DMark2003, so your better performance may come at quality loss (sometimes noticable). Both ATI and Nvidia have been caught previously doing rendering cheats on the windows platform. Also some things can't be included in an open driver like patented S3 Texture Compression. Chris
Re: Debian menu system update
On Tue, Jun 03, 2003 at 12:24:34PM +0200, Bill Allombert wrote: > On Sun, Jun 01, 2003 at 11:08:00PM -0400, Colin Walters wrote: > > > I have read it, and I have still difficulty to understand its > > > full implication. > > > > The implication is basically that we use it as the format of our menu > > database (instead of /usr/lib/menu), and convert the menu-methods to > > taking that information and translating it to legacy formats such as the > > fvwm menu system. > > How GNOME and KDE will honor menu configuration in /etc/menu, > /etc/menu-method/menu.h, ~/.menu and ~/.menu-method/menu.h with your > scheme ? As I understand it, those would go away entirely. All menu entries would be in /usr/share/applications, or $HOME/.local/share/applications as per desktop menu specification. The menu's themselves would go into /etc/xdg/menus, or $HOME/.config/menus/ (If I have read the basedir and menu specs correctly). Chris
Re: Debian menu system update
On Tue, Jun 03, 2003 at 08:39:02PM +0200, Bill Allombert wrote: > How do you expect menu to generate menus without an /etc/menu-method/ > directory ? Also autogenerated menus should go in /var. Oops you are correct, for window managers that don't support the spec natively we still need that directory. Chris
Re: Debian menu system update
On Tue, Jun 03, 2003 at 09:13:09PM +0200, Bill Allombert wrote: > On Tue, Jun 03, 2003 at 02:08:38PM -0500, Chris Cheney wrote: > > On Tue, Jun 03, 2003 at 08:39:02PM +0200, Bill Allombert wrote: > > > How do you expect menu to generate menus without an /etc/menu-method/ > > > directory ? Also autogenerated menus should go in /var. > > > > Oops you are correct, for window managers that don't support the spec > > natively we still need that directory. > > Then could you answer my original question again ? As far as I can tell /etc/menu, /usr/lib/menu, and /usr/share/menu will go away once we start using the desktop entry spec and /usr/share/applications directory. Anything natively supporting the desktop spec won't have any reason to use /etc/menu-method at all (afaik). The desktop menu spec will probably need an addition of $XDG_CONFIG_DIRS/applications/ to replace debian's /etc/menu that is a global admin menu entry directory. Chris Cheney Debian KDE Maintainer PS - I am cc:ing this to xdg-list so that the proper people can see that a global applications override directory would be a useful addition. Please note that I am not subscribed to xdg-list.
Re: May packages rm -rf subdirectories of /etc/ ?
On Mon, Jul 21, 2003 at 07:06:17AM +0200, Thomas Hood wrote: > Recently I purged a package foo which had a configuration directory > /etc/foo/. The package contained a number of conffiles in /etc/foo/ . > I backed up some of these before the purge by copying them to other > names, but leaving them in /etc/foo/ . To my surprise, the package > postrm did a "rm -rf" on the whole /etc/foo/ directory, thus > deleting my backups. > > Looking at the postrms of other packages I have installed, I see that > a handful of them do likewise. > > Now, on one hand I can see that given the current state of Debian's > packaging tools, removing an entire directory can be the convenient > thing to do. If a package maintains a bunch of configuration files > (not conffiles -- dpkg knows how to delete those) in the directory > then "rm -rf" is sure to remove them all. > > However, "rm -rf" is always a dangerous command to use. Configuration > directories are often shared; add-on packages may store things in the > configuration directories of the packages to which they add things on, > especially if the latter uses run-parts to run hook scripts. Sometimes > one package Replaces another and hijacks the latter's configuration > files; but these will be improperly deleted if the admin later purges > the original package. And admins may store things in /etc/ > subdirectories. I think it would be better if packages removed only > files that they have created. > > One may want to treat /etc/foo/ differently from, e.g., /var/lib/foo/ . > I would never store anything additional in /var/lib/foo/ because it > wouldn't surprise me if a package did "rm -rf /var/lib/foo/" on purge. > > I know of no policy section that pronounces on this. Am I overlooking > one? > > If not, what do think of this? When is it OK for a package to > "rm -rf /etc/foo/" on purge? rm -rf /etc/foo really shouldn't be needed except in the cruft related cases other people have brought up, which just as easily could be done by removing with wildcards for particular types of tempfiles. There is one glaring problem though... dpkg does not remove empty dirs under /etc on purge. This is a long standing bug in dpkg. [0] Personally I just leave the /etc dirs my packages create on purge, its a f*cking bug in dpkg and I don't feel like trying to hack around it. Chris [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=58878 (24 Feb 2000)
Re: [PROPOSAL] Debian Release Plan
On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote: > On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote: > > > Matt Zimmerman <[EMAIL PROTECTED]> wrote: > > > On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote: > > [...] > > > > If there are RC bugs to packages that 'release-status-sarge' depends > > > > on, it won't go to testing... > > > > > > Of course it would, unless it had a versioned dependency that could > > > not be met. And how would you know in which version the bug would be > > > fixed? > > > > 'release-status-sarge' is just a package to monitor the work to be done > > to have a stable release. > > > > It does not matter to know in which version the bug will be fixed. What > > I want for sarge is emacs21 ( >= 21.2 ) so if every RC bugs are closed > > with 21.3 or 21.4, the dependency >=21.2 is ok. > > And what if the version in testing has an RC bug? "release-status-sarge" > says everything is OK. Do we even know which packages in sarge have RC bugs? The last time I looked when you close a bug with an upload to sid it closes it entirely still. So we don't really have a good idea of how many RC bugs exist in sarge, only how many are in sid. Chris
Why is sbcl getting installed during buildd builds?
I noticed that several of my packages are failing to build on quite a few buildds. This is due to the sbcl maintainer uploading a broken version of sbcl today (afaict). However, my package doesn't even depend on sbcl at all, I use clean chroots to build my packages locally for i386 and it is not installed in it. Why is this package being pulled in?! Examples: kdeadmin- alpha, powerpc kdegraphics - alpha, powerpc, sparc Thanks, Chris Cheney
Re: Why is sbcl getting installed during buildd builds?
I think we determined on #debian-devel that the problem is that the alpha, powerpc, and sparc buildds are broken and need manual intervention to remove the sbcl package. Chris
Re: Aaargh!
On Fri, Aug 01, 2003 at 11:36:58PM -0400, Nathanael Nerode wrote: > I feel a little like screaming. -snip- Ouch I didn't realize it was that bad :\ The list of problems I currently know about for KDE are: 1. ia64 gcc 3.3 bug 2. s390 glibc kernel header ptrace.h violates ISO C [0] 3. xfree86 4.2.1-10 needed for mips/mipsel On the bright side maybe we will be able to get KDE 3.2 in before the sarge release then. ;) Chris [0] gcc 3.3 is more anal about ISO conformance now, I probably need to open an RC bug on glibc about this soon. (affects kdebase)
Re: [PROPOSAL] Debian Release Plan
On Sat, Aug 02, 2003 at 01:15:53PM -0400, Nathanael Nerode wrote: > Matt Zimmerman said: > >I disagree. If I'm not mistaken, this is the definition of an RC bug. > >If > >the package has an RC bug, it is not releasable. If there is an RC bug > >which does not imply that the package is unreleasable, it has been > >assigned > >the wrong severity. > > So you're saying bug #196564 should be downgraded then? I don't think > that *possibly* causing a segfault in another package (it's not clear > that it still does), on *one* architecture (m68k), when it's *probably* > a toolchain issue, and the m68k people don't have the time or interest > to reproduce it or track it down, should imply that the package is > unreleasable! I am about to be closing 196564 since it does not seem to be reproducable, meinproc is used in every kde app during the build process and it is working. Thanks, Chris
libraries being removed from the archive
Today I was reminded of something that causes apps not to migrate into sarge. When maintainers remove old libraries from the archive! Today for example libexif8 was removed by Christophe Barbe and replaced by libexif9. Guess what that does... any package which depends on libexif8 now becomes... you guessed it... UNINSTALLABLE! Why does this annoy me in particular, because I just uploaded kdegraphics yesterday which was built against libexif8. Guess how many hours it takes for the m68k buildd to rebuild kdegraphics. OVER 38 HOURS! IMHO we need to make an addition to policy stating that an old lib can not be removed from the archive until no other packages still depend on it. Chris Cheney
Re: libraries being removed from the archive
On Sun, Aug 03, 2003 at 08:55:48AM +0200, Eduard Bloch wrote: > #include > * LapTop006 [Sun, Aug 03 2003, 03:13:57PM]: > > > > IMHO we need to make an addition to policy stating that an old lib can > > > not be removed from the archive until no other packages still depend on > > > it. > > How about old libraries can not be removed until either no packages > > depend on it OR the author files RC bugs with any dependent pakcages > > (and hopefully waits for at least a day in case of any major problems)? > > Old libraries are removed since only one version can exist in the same > distro branch to the same time. If the library maintainer decided not to > fork the source package but change the binary package name inside of > existing three then he does not care about the users of his package. > Such actions (in-place transition) should always be done in coordination > with fellow developers as happened in the Perl transition, for example. Hence the need for policy to dictate to the maintainer not to allow the package to be removed before all other packages have transitioned. It usually doesn't take much more work as long as the maintainer is even aware of what will happen. Chris
Re: libraries being removed from the archive
On Sun, Aug 03, 2003 at 03:55:41PM -0400, David Z Maze wrote: > Chris Cheney <[EMAIL PROTECTED]> writes: > > > IMHO we need to make an addition to policy stating that an old lib can > > not be removed from the archive until no other packages still depend on > > it. > > So say I maintain foo. The source package produces two binary > packages, foo and libfoo1. Now, there's a new foo release, that > changes libfoo's soname. In the current scheme, I package the new > upstream release and upload foo and libfoo2; since there's no source > package for libfoo1, it eventually gets removed from unstable. > > Are you proposing that (a) the ftpmasters not remove libfoo1, or (b) > that package maintainers of library packages are now compelled to > package the last version of foo's source providing libfoo1 separately, > potentially for multiple release cycles for a widely used library? > Option (b) sounds problematic to me... libfoo1 gets automatically removed immediately upon installation of libfoo2 in the archive currently. The proper way to fix this issue is when the maintainer uploads new libfoo source with libfoo2 package in it to also upload a source called libfoo1 that only provides the libfoo1 binary package [0]. I have done this myself for libao0 in the past. Once libfoo1 is no longer used by anything you can simply remove it from the archive without having to modify anything. I seriously doubt at the speed of Debian's "release cycle" you would need to have the old library in the archive for more than one release, probably not even that long. You do realize that Debian's "release cycle" is currently 2 years per release...? Chris Cheney [0] Both the libfoo and libfoo1 source will be marked NEW so assuming that both get processed at the same time packages depending on libfoo1 won't become uninstallable.
Re: libraries being removed from the archive
On Sun, Aug 03, 2003 at 05:31:37PM -0400, christophe barbe wrote: > You are kidding right? > > I have not removed an old library, I have uploaded a newer upstream with > a different soname. That's the way it works, a new library is uploaded, > then packages using it are rebuilt and when they are all ready they > migrate in testing. > > As the gphoto2 maintainer, I don't remember getting mails from you > announcing an upcoming libusb package with a new soname. Perhaps that's > because I was waiting for a few months to get a working one for our > powerpc users. > > IMHO we need to make an addition to the policy stating that not being an > asshole on the mailing-list is welcome. I don't remember sending mails > to the mailing list when the libusb packaging was broken for a few > months, but I do remember sending you polite mails. > > For you information, some packages using libexif need libexif9. > I agree that I could (should) have sent a prior notice before uploading it > (more than a week ago, BEFORE your kdegraphics upload), but that's not > an excuse to be an asshole. > > Christophe You aren't the only one that has broken things, many other people including myself have as well, I most notably with libvorbis ;). However, this libusb soname change you mention last happened on Feb 27 2002, which was changed due to a RC bug regarding its naming. (BTW libusb's soname is odd, which is why I didn't catch it sooner). Also you mention that libusb was broken for several months, which is true, but it was only broken on one arch (powerpc). Also, from what I can tell from looking back at it by the time you determined it wasn't a bug in gphoto2 you NMU'd it within a week. I don't recall if I was actually aware of the bug before you NMU'd it. Also, I was not stating that libexif9 should not be uploaded, only that old libraries should not be removed from the archive until they are no longer used, which apparently was not the case for libexif8. I don't recall if I stated this earlier but each time I have uploaded KDE in the past several months it has been broken by library removals within about a week and recompiling KDE sources is not light work for the buildds. Seriously, if we want to ever release sarge we are going to need to stop making libraries disappear, every time we rebuild something it takes another 10 days for it to migrate into testing and everything that depends on it is also pushed back another 10 days. Even if the person causing the breakage NMU's all the affected packages it still causes them to wait another 10 days to migrate, and causes unneeded load on the buildds, possibly with the packages no longer being able to be built since gcc 3.3 is so anal now. (/me wonders how many RC bugs are around just for gcc 3.3 related crap) BTW - For those wondering Woody was released over a year ago... Thanks, Chris Cheney PS - I apologize for sounding like an asshole, however this general problem really does need fixing.
Re: About NM and Next Release
On Wed, Aug 06, 2003 at 05:29:54PM +0300, Halil Demirezen wrote: > I am currently on NM process. And as far as I know, there have been > totally over 700 developer of Debian officially. > > What I would like to point out here is, totally over the world claims > that debian is being obsolete. New releases are so slow. Yes they are > partially right. However, with 700 maintainers, Debian is slow. We would > like to be a part of Debian through NM process. However, NM process > cause a deeply undesireble emotions on applicants because of 2-3 > years wait duration. To me, opposing to the policies Debian is on > progress to be a Mysterious box to the outside world. > > We believe we could be helpful. However, We are trying to be cut off > from that project. Totally this is agaist prejudice on Policies.. and > DFSG. > > Debian Maintainers are becoming too elite. However, outside world becoming > more excluded. And Debian finally is becoming so obsolete. Debian has had a very slow NM process for a very long time, it took over a year for me to be processed when I became DD in July 2000. That was before the new NM queue structure that is in place now. The only people actually waiting that long now (aiui) are people James does not want in the project at all. It would be good to get rid of their applications entirely so that other prospective maintainers don't get the wrong idea that it takes 2-3 years to be processed. Also, it seems like most DD's don't maintain many packages anyway. Yes there are other things that a DD can do other than just maintain packages, like help with web translations, boot floppies, etc. But nearly two thirds of the developers/sponsored developers maintain 4 sources or less [0]. If even half of those 746 maintainers focused on helping close RC bugs we would probably be close to releaseable today. We don't need more people to throw at the problem, we need more people willing to do work for the project. Chris [0] http://www.debian.gr.jp/~kitame/maint.cgi?num=srcs&limit=1300&maint= 1226 Maintainers Total 480 - 4 61% 575 - 3 53% 719 - 2 41% 878 - 1 28%
Re: About NM and Next Release
On Wed, Aug 06, 2003 at 08:01:35PM +0200, Francesco Paolo Lovergine wrote: > On Wed, Aug 06, 2003 at 05:10:24PM +0200, Eduard Bloch wrote: > > Interessting analysis. Many things that hold up the release can only be > > solved by active and experienced maintainers since the packages are often > > essential. New developers can help maintaining them in cooperation with > > main developer and get the experience after some time and reading of the > > policy, developers reference, lib packaging guide, etc, but having a > > sponsor between them and the upload queue is still better. > > > > Someone should point NMs to difficulty of entering the development > mainstream of FreeBSD or becoming maintainer for the kernel... > IMO it's generally too easy entering in Debian. Becoming a maintainer of a new driver for the Linux kernel isn't that difficult. You just have to convince a subsystem maintainer to take your driver, which IME isn't very hard, definitely simpler than becoming a DD. Chris
Re: About NM and Next Release
On Wed, Aug 06, 2003 at 01:41:45PM -0500, Adam Heath wrote: > On Wed, 6 Aug 2003, Chris Cheney wrote: > > Not to toot my own horn, but I was accepted in under one week. I took 2 weeks > to read up on everything, then after I sent in my app, less than a week later > I was accepted. > > The shortness can probably be attributed to me actually doing work. This was > during the libc5->libc6 transition, and I was recompiling 3-4 packages each > day, and posting nightly summaries on -devel(this list). I wasn't hounding > DSA to accept me, I was just showing what work I was doing. Others on the > list, however, were clamouring for my acceptance. > > Of course, after I was accepted, I stopped doing 3-4 recompiles a day; I don't > know what that means. > > (I was accepted in January, 1998). Yep, this was before NM was closed indefinitely. From sometime around early 1999 until mid 2000 (June iirc) NM was closed, as far as I know no one at all was accepted into Debian during this time. IIRC Wichert finally got the ball rolling to start accepting new maintainers around April 2000. I don't know the current average time for a NM to get through the queue but I would guess at it being around 3-4 months. Chris
Re: About NM and Next Release
On Thu, Aug 07, 2003 at 05:10:01PM +0100, Scott James Remnant wrote: > I've always thought KDE a wonderful example of what happens when you > give commit access to just about anybody too. > > Scott > (GNOME user) Oh you mean the fact that KDE has rapid development... Yep. ;) Chris
Re: Bits from the RM
On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: Content-Description: signed data > On Tuesday 19 August 2003 08:49, Anthony Towns wrote: > > > I'm all for aggressive goals, let's aim for sometime in December -- how > > about 2003-12-01 00:00:00 UTC? > > Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, > gnome versions will be in sarge? An educated guess would produce: GCC 3.3.1 Gnome 2.2 (2.4 will probably be out before freeze but whether it goes in is up to them...) [0] KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) XFree 4.3.0 (Branden wants this to happen...) Chris Cheney [0] http://www.gnome.org/start/2.3/
Re: Bits from the RM
On Wed, Aug 20, 2003 at 04:34:18PM +0200, cobaco wrote: > > KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by > > almost two months: > > > > * October 15th > >Final, last-minute, low-risk bug fixes only > > Monday September 29th, 2003: Preparing Beta1 > The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits[1] > > is there any reason why stabilization of kde and stabilization of > kde-packaging can't be done in parallel? Er you want the final version of KDE in stable to be a KDE 3.2 Beta 1 release? ;) It takes well more than 10 days on average for KDE to be ready to migrate to sarge, esp with slow buildds such as m68k and mips. And with KDE 3.2 Beta 1 releasing to packagers on Sept 29 it won't have even finished building on the buildds much less waited the required 10 days by Oct 1. Debian 3.1 Dates Sept 1 Toolchain freeze. Sept 15 Major package freeze. Oct 1 Everything freezes(?) Chris
Re: Bits from the RM
On Wed, Aug 20, 2003 at 08:49:44PM +0200, Martin Quinson wrote: > What recent change in the KDE releasing schema let you think that they will > manage to get a really stable x.y.0 release [*] when it seems like it took 4 > minor releases in the 3.1 branch ? > > Naturally, no offense intended to the kde guys. Needing only 4 minor releases > to stabilize such an amount of code is really great. > > > Bye, Mt. > > [*] ie, suitable for debian stable release, ie a version with which you > could live for a year on your desktop, maybe dreaming of new features (we > always want more), but not pesting against the bugs. > I speak of course of the ideal debian stable release ;) KDE usually releases new point releases about every two months until the next major release happens. Then they only update for security related bugs. It doesn't magically become stable after 4 releases. Chris
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Mon, Aug 18, 2003 at 02:21:55PM -0600, Joel Baker wrote: > No, it is based on the assumption that a buildd will only install things > listed in the Build-Depends, which means it will catch stuff that only > builds on the maintainers workstation because they aren't building > inside a chroot and are being sloppy - one of the main things they catch > for binary-arch targets, today. This is (or was) not the case, buildds often have other things installed on them other than build-essential. I have been bitten by this in the past. Also, I have a build failure from the arm buildd on Aug 21 (kdebase) that smells like it, it couldn't install libcupsys2-dev which I bet is caused by gnome related packages being installed on the buildd (#203059). Also, I have been told before buildds in general have various other packages installed to save on install time, however I don't know if this is actually true. Chris Cheney pgp5prSRABZOD.pgp Description: PGP signature
Re: .iso conflict, discussion of resolution
Stephan, Would it be possible to get the two desktop filesi mentioned below merged into kdelibs so that arson and k3b are easily installable at the same time? I can do the commit myself if you approve. Thanks, Chris Cheney Debian KDE Maintainer PS - Christian/Jean-Michel there is a new debian-qt-kde developer mailing list for Qt/KDE debian maintainers, debian-kde is still available for users. On Fri, Aug 29, 2003 at 10:34:39PM -0700, Mike Markley wrote: > All, > > A quick summary of this bug: > Arson, a KDE CD burning application, includes two .desktop files to > associate certain files with it: > /usr/share/mimelnk/application/x-iso.desktop > /usr/share/mimelnk/application/x-cue.desktop > > For more info on what's been suggested and what's been discussed, see > 195214, 195218, and 203954. pgp2OTQn6ZCJZ.pgp Description: PGP signature
Re: .iso conflict, discussion of resolution
On Sat, Aug 30, 2003 at 06:08:17PM -0400, Matt Zimmerman wrote: > On Fri, Aug 29, 2003 at 10:34:39PM -0700, Mike Markley wrote: > > > A quick summary of this bug: > > Arson, a KDE CD burning application, includes two .desktop files to > > associate certain files with it: > > /usr/share/mimelnk/application/x-iso.desktop > > /usr/share/mimelnk/application/x-cue.desktop > > And presumably another application also wants to include these files? Is > KDE's file association system really so broken that two programs cannot both > declare themselves able to handle a certain type of file? Nope, mime types are completely independent of them declaring if they support it. That is why the mimetype really belongs in kdelibs itself and not the 3rd party package. Chris pgpbRneFe2HLg.pgp Description: PGP signature
Re: Debian should not modify the kernels!
On Mon, Sep 22, 2003 at 09:31:49PM +1000, Herbert Xu wrote: > George Danchev <[EMAIL PROTECTED]> wrote: > > > > it is faster and wiser to fix your kernel-source-2.4.22 (unpatch is > > useless, > > leave to users to patch if they want) then all other > > kernel-patch- > > packages will be fine. > > It is unacceptable for us to distribute kernels with known (security) bugs. Is there a particular reason we are distributing old kernels at all? I see the following in the archive: kernel-source-2.2.25 old - kernel-source-2.4.19-hppa old - kernel-source-2.4.19 old - kernel-source-2.4.20 old - kernel-source-2.4.21 kernel-source-2.4.22 old - kernel-source-2.5.69 old - kernel-source-2.6.0-test2 old - kernel-source-2.6.0-test4 A current kernel shouldn't have known security holes in most cases and if it does security fixes (ONLY) should be applied. I do recall the case where the kernel didn't have a root hole fixed for a while earlier this year, but that seemed to be caused by no one knowing how to fix the hole properly without breaking other things. A kernel that has no security fixes should be identical to upstream except for whatever happens to be in the debian dir. On a related note, it would be nice if stable could have updated kernels since it is somewhat difficult to install Debian on modern systems when the newest kernel in stable is 1.5 years old (2.4.18 Feb 25 2002). For my last three systems I have had to download knoppix and use debootstrap to install. A newbie would likely just give up. Chris BTW - linux-2.6.0-test5 was released Sept 8.
Buildd's using really old packages
I noticed while verifying that the buildds weren't still using the buggy g++ 3.3.2-0pre4 that some are using 3.3.2-0pre1 which is 6 weeks old. Is there a particular reason some of the buildds are so out of date? Chris signature.asc Description: Digital signature
Re: Where are we now? (Was: Bits from the RM)
I still need to get KDE 3.1.4 into sid and stablized. I hope for it to be ready to migrate into sarge by Oct 20 (including the 10 day wait time). From what Colin Watson mentioned to me earlier today there are some other packages that are holding KDE out as well so hopefully they are resolved by then. Chris Cheney signature.asc Description: Digital signature
Re: Which packages will hold up the release?
On Thu, Oct 02, 2003 at 12:38:57PM +0200, Peter Makholm wrote: > I believe this is the bugs it would be most effective to actack when > the packages I'm personally directly interested in. It can be hard to > look at the RC-list and decide if the time is better spend fixing > libtse3, libvorbisfile3, or fam. Ogg Vorbis is close to a release which is why almost all bugs related to it are marked pending. If they don't actually release soon I will be uploading cvs snapshots of all the related packages. The only thing holding them up at the moment is getting it to build properly on win32. Thanks, Chris signature.asc Description: Digital signature
Re: Re: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 08:31:08PM +0200, Robert Lemmen wrote: > On Thu, Oct 02, 2003 at 01:14:25PM -0400, Nathanael Nerode wrote: > > Please don't do this yet, since dselect is still more self-documenting, > > and therefore easier for new people to use. :-P > > please do! dselect (whil ebeing verty simple and functional) has the > most counter-intuitive user interface i have seen. the day i discovered > aptitude and got rid of dselect meant a big step forward for my persoanl > debian experience. From what I have heard about aptitude it has the fun side effect of removing packages that it thinks you didn't purposely install. Also aptitude's sort function was more user unfriendly than dselect by far (just hit 'o'). I happen to use the sort option in dselect often. If aptitude can be used as dselect is now, eg hit 'g' to download just standard it will be ok I suppose. I also don't think it is a particularly good idea for aptitude to default to installing suggests since it will likely bloat systems quite a bit installing various things such as bash-doc, gpart, parted, etc. Also, it will automatically install packages in non-free (when user has non-free listed) since packages in main are allowed to suggest non-free. Further, if recommends/suggests are on how does a user manage to only install standard using aptitude? Maybe there should but a tasksel option for just installing standard and above? I am not against aptitude, or a better package management tool in general, I just don't like the way aptitude currently "works". Chris Cheney signature.asc Description: Digital signature
Re: Re: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 10:09:16PM -0400, Daniel Burrows wrote: > On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney <[EMAIL PROTECTED]> > was heard to say: > > I also don't think it is a particularly good idea for aptitude to > > default to installing suggests since it will likely bloat systems quite > > a bit installing various things such as bash-doc, gpart, parted, etc. > > aptitude doesn't depend on any of those. Do you mean when installing > other packages? If too much stuff is being pulled in from Recommends, > the package maintainers are using Recommends incorrectly. I haven't > found this to be a problem in practice. I meant since aptitude defaults to installing suggests by default, there are packages in standard and above that suggests many things that a normal user would not really care to have installed. I just installed aptitude on my system today to see how it works now (I hadn't looked it in several months) and noticed all the options under Options->Dependency Handling all the options were X'd which means selected right? I can't paste it here since aptitude seems to have mouse support so copy/paste doesn't work. > > Also, it will automatically install packages in non-free (when user has > > non-free listed) since packages in main are allowed to suggest non-free. > > aptitude installs Recommendations by default because this is what > Recommandations mean. It does not install Suggestions because > Suggestions are not meant to be installed by default. If you are > installing packages from contrib (which can Recommend and even Depend on > stuff in non-free), you should expect to get non-free stuff on your system. As stated above aptitude does apparently now default to '[X] Install Suggested packages automatically' as well. As I did not turn it on myself and I even removed ~/.aptitude several times to verify it was still enabled. Chris signature.asc Description: Digital signature
Re: Re: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 11:09:29PM -0400, Daniel Burrows wrote: > On Thu, Oct 02, 2003 at 09:59:58PM -0500, Chris Cheney <[EMAIL PROTECTED]> > was heard to say: > > On Thu, Oct 02, 2003 at 10:09:16PM -0400, Daniel Burrows wrote: > > > On Thu, Oct 02, 2003 at 04:10:21PM -0500, Chris Cheney <[EMAIL > > > PROTECTED]> was heard to say: > > > > I also don't think it is a particularly good idea for aptitude to > > > > default to installing suggests since it will likely bloat systems quite > > > > a bit installing various things such as bash-doc, gpart, parted, etc. > > > > > > aptitude doesn't depend on any of those. Do you mean when installing > > > other packages? If too much stuff is being pulled in from Recommends, > > > the package maintainers are using Recommends incorrectly. I haven't > > > found this to be a problem in practice. > > > > I meant since aptitude defaults to installing suggests by default, there > > Hm, it does. I thought I fixed that ages ago. > > Just for some background: this wasn't supposed to happen, because > turning suggests on is a really bad idea, but I apparently accidentally > set it to "true" in one place in the code and "false" in another place > and in the documentation. I thought I fixed this at one point in the > past, but apparently not. > > What happens is that the default state is actually false, but if > you go to the preferences dialog, the preferences dialog shows that it's > selected and selecting "Ok" causes the setting to be changed. Ah ok, I'm glad I was able to point it out before release. :) > > Handling all the options were X'd which means selected right? I can't > > paste it here since aptitude seems to have mouse support so copy/paste > > doesn't work. > > Just FYI, you can use Shift to override mouse support in programs. Thanks, I didn't know about that either. BTW - Is there a way to see what a package provides under its information screen? It seems to display just about everything else but that. Chris Cheney signature.asc Description: Digital signature
Re: How tightly should main be self-contained?
On Fri, Oct 03, 2003 at 09:40:27AM -0400, Simon Law wrote: > Hi guys, > > Some users have approached me about my packaging on tvtime, which lives > in main. It benefits greatly from libdscaler, a contrib package. They > are asking that tvtime Suggests libdscaler. I thought that the > appropriate thing to do was to have libdscaler Extends tvtime. Packages in main suggesting contrib/non-free or nonexistant packages altogether is fine (afaik). However, does anything even support the Extends field yet, I was under the impression it was still only a human usable field? Chris signature.asc Description: Digital signature
Re: Where are we now? (Was: Bits from the RM)
On Fri, Oct 03, 2003 at 10:13:36AM -0400, Stephen Frost wrote: > Or, alternatively, this was the only crappy NMU that was noticed while > quite a few others were made against ancient packages with inactive > maintainers who didn't notice or didn't care. I'm not terribly > interested in going through all the NMUs done and attempting to prove > this but I find it more likely than the possibility that only one poor > NMU was done during that period. kdemultimedia was broken via NMU as well, but I don't hold that against lamont since he did many other proper and useful NMUs. ;) KDE in general is not a good thing to NMU since it is very complicated and breaks easily. Although I still don't understand how lamont managed to get his NMU to compile on his own machine since it didn't compile on any other arch. Chris signature.asc Description: Digital signature
/usr/doc symlinks
I thought that it was planned that /usr/doc not exist for the sarge release. However, I still see symlinks in /usr/doc is this considered a bug or are we waiting until sarge+1 to do this? BTW - I still see one package that installs files directly into /usr/doc usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param graphics/ucbmpeg Chris Cheney signature.asc Description: Digital signature
Re: /usr/doc symlinks
On Sun, Oct 05, 2003 at 08:57:37AM +0100, Colin Watson wrote: > On Sun, Oct 05, 2003 at 01:59:10AM -0500, Chris Cheney wrote: > > BTW - I still see one package that installs files directly into /usr/doc > > > > usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param graphics/ucbmpeg > > Where's this data from? The version of ucbmpeg in testing and unstable > appears to use /usr/share/doc as it's supposed to. I grepped a current Contents-i386.gz for usr/doc, and after examining the file itself I notice it is from a comment in the front of Contents-i386.gz... ARGH!!! Sorry about the confusion. Chris The best way to search quickly for a file is with the Unix `grep' utility, as in `grep CONTENTS': $ grep nose Contents etc/nosendfile net/sendfile usr/X11R6/bin/noseguy x11/xscreensaver usr/X11R6/man/man1/noseguy.1x.gzx11/xscreensaver usr/doc/examples/ucbmpeg/mpeg_encode/nosearch.param graphics/ucbmpeg usr/lib/cfengine/bin/noseyparkeradmin/cfengine signature.asc Description: Digital signature
Hardcoding of .la file paths in .la files
Does anyone happen to know why .la files hardcode the paths to .la files that they depend on? For example: dependency_libs=' -lm -L/usr/lib /usr/lib/libogg.la' This is about to bite Debian hard with some of the XFree86 libraries moving to /usr/lib. Chris Cheney --- # libvorbis.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4.2a (1.922.2.100 2002/06/26 07:25:14) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libvorbis.so.0' # Names of this library. library_names='libvorbis.so.0.2.0 libvorbis.so.0 libvorbis.so' # The name of the static archive. old_library='libvorbis.a' # Libraries that this one depends upon. dependency_libs=' -lm -L/usr/lib /usr/lib/libogg.la' # Version information for libvorbis. current=2 age=2 revision=0 # Is this an already installed library? installed=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib' signature.asc Description: Digital signature
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 07, 2003 at 10:26:45AM +0200, Marcelo E. Magallon wrote: > On Tue, Oct 07, 2003 at 01:33:01AM -0500, Chris Cheney wrote: > > > Does anyone happen to know why .la files hardcode the paths to .la > > files that they depend on? > > Anal-retentiveness wrt using the exact same library originaly used. > > > This is about to bite Debian hard with some of the XFree86 libraries > > moving to /usr/lib. > > Can you be more specific? -rw-r--r-- 22k 2003-10-07 01:49 libxrender1_0.8.3-1_i386.deb The new version of libXrender moves from /usr/X11R6/lib to /usr/lib which has already started to cause build failures... :\ I am not certain if Branden plans to move any others to /usr/lib, but if he does hopefully he will do it very soon. Chris signature.asc Description: Digital signature
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 07, 2003 at 09:30:56AM +0100, Scott James Remnant wrote: > On Tue, 2003-10-07 at 07:33, Chris Cheney wrote: > > > Does anyone happen to know why .la files hardcode the paths to .la files > > that they depend on? > > > To guarantee that you don't end up linking with something totally > different if the app being compiled happens to have a different search > path. > > What's more of a problem here is that libtool actually links dependency > libraries of dependencies ... it's something I've been working on for a > while. I seem to recall you working on that earlier this year, how is it coming along? > > This is about to bite Debian hard with some of the XFree86 libraries > > moving to /usr/lib. > > > How? XFree86 doesn't use generally use libtool -- I only see > libXrender.la in my /usr/X11R6/lib Which is the one moving to /usr/lib. (I am not sure if any others are planning to be moved.) Chris signature.asc Description: Digital signature
Re: Hardcoding of .la file paths in .la files
On Tue, Oct 07, 2003 at 02:58:25PM -0500, Branden Robinson wrote: > I think the problem with .la files may be solvable by updating > Build-Depends and -dev packages' dependencies to refer to libxrender-dev > (>= 0.8.3-1), and/or libraries that are rebuilt against that version of > libxrender-dev. I'm looking into it. I think the problem is worse than that due to the recursive linking that Scott mentioned. Once recursive linking is removed from libtool then it would be a simple matter of recompiling only those libraries which directly depend on libXrender/libXft. As it is any library that links against a library using libXrender/libXft will need to be recompiled. We need to get the new libXft into sid asap so the breakage doesn't happen again. Chris --- The potential affected sources list is: (106 sources) abiword anjuta arson avifile bibletime bookcase brahms cdbakeoven celestia control-center drscheme eel2 epiphany-browser evas facturalux fltk1.1 fontilus freesci galeon gnome-mag gnome-system-tools gnome-terminal gnustep-back gst-player gthumb gtk+2.0 guarddog htmldoc icewm idesk k3b kbarcode kbear kcd kcpuload kdbg kdeaddons kdeadmin kdeartwork kdebase kdegames kdegraphics kdelibs kdenetwork kdepim kdesdk kdetoys kdeutils kdirstat kflog kile kimagemapeditor klineakconfig klog kmymoney2 knapster2 knetload knutclient koffice komba2 konq-speaker kopete kphone kprof ksensors ksimus ktrack kvdr kvirc kwavecontrol lesstif1-1 matchbox mgp mlterm motv mozilla mozilla-firebird mozilla-snapshot nautilus nautilus-cd-burner nautilus-media openbox openexr pango1.0 plptools qt-x11-free quanta rosegarden4 sawfish scribus seaview sim slicker sodipodi spiralsynthmodular superkaramba unixodbc vimpart vte waimea xawtv xcursor xfree86 xft2 xrender zynaddsubfx signature.asc Description: Digital signature
Re: Hardcoding of .la file paths in .la files
On Wed, Oct 08, 2003 at 06:12:17AM +0100, Scott James Remnant wrote: > Actually the problem is somewhat lessened by the fact libtool generally > doesn't put the .la path in dependency_libs and puts -lXrender instead. > > The *only* package I can see so far which has > /usr/X11R6/lib/libXrender.la in it is vte: > > elite scott% grep libXrender\.la /usr/lib/*.la > /usr/lib/libvte.la:dependency_libs=' -L/usr/X11R6/lib > /usr/lib/libgtk-x11-2.0.la /usr/lib/libgdk-x11-2.0.la > /usr/lib/libatk-1.0.la /usr/lib/libgdk_pixbuf-2.0.la -lm > /usr/lib/libpangoxft-1.0.la /usr/lib/libpangox-1.0.la > /usr/lib/libpango-1.0.la /usr/lib/libgobject-2.0.la > /usr/lib/libgmodule-2.0.la -ldl /usr/lib/libglib-2.0.la -lXft > /usr/lib/libfreetype.la -lz /usr/X11R6/lib/libXrender.la -lfontconfig > -lSM -lICE -lX11 -lncurses' It appears all of kde has it included as well. Does this happen to have anything to do with the rpath'ing issue that some of the XFree libs are causing as well? (iirc it was xrender) > To remove "recursive linking" you'd need to recompile/rebuild > *everything* using libtool, after libtoolizeing with the new libtool. I > mean everything too, that's a big job. Yea, however new libtool is needed for arm anyway so has recently been updated on many packages. Chris signature.asc Description: Digital signature
Re: Question about libcdda_paranoia
On Wed, Oct 08, 2003 at 04:58:34PM +0200, Henning Moll wrote: > On Wednesday 08 October 2003 13:27, Colin Watson wrote: > > No, plain .so links are only needed for build-time linking, and > > therefore live in development packages. > > Thank you for that information! > > But now i am in a bit of trouble: i packaged a woody backport of k3b. > This programm tries to dlopen (=at runtime) 'libcdda_paranoia.so'. But > that is only possible if package 'libcdparanoia0-dev' is installed. Look at the debian dir of the package you are backporting. ;) Hint - k3b-0.9/debian/patches/02_k3bcdparanoialib.dpatch Chris signature.asc Description: Digital signature
Re: gnome???
On Wed, Oct 08, 2003 at 02:00:42PM -0800, Ivan Jelic wrote: > is there any chance for gnome 2.4 to be included in sarge? maybe as > option? which desktop enviroments are you planing to include in sarge? Currently as far as I know Gnome 2.2, KDE 3.1.4 and XFCE 4.0 will be in sarge. There were some plans on getting Gnome 2.4 into sid and possibly sarge but I don't know the current status of this plan. The Gnome team wanted to insure that all of Gnome 2.2 was in sarge before transitioning to Gnome 2.4. Chris Cheney signature.asc Description: Digital signature
Re: Package which uses jam (instead make)
On Fri, Oct 17, 2003 at 08:24:20PM +0200, Josip Rodin wrote: > On Fri, Oct 17, 2003 at 12:20:03PM -0400, Ben Collins wrote: > > You aren't trying to make debian/rules a jam script are you? > > Even if he was, that would be fine if he knew how to do it properly. It would? 4.8. Main building script: `debian/rules' - This file must be an executable makefile, and contains the ^^ package-specific recipes for compiling the package and building binary package(s) from the source. Chris signature.asc Description: Digital signature
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
On Sun, Oct 19, 2003 at 08:15:43PM +0100, Andrew Suffield wrote:
> On Sun, Oct 19, 2003 at 01:20:39PM +0100, Scott James Remnant wrote:
> > On Sun, 2003-10-19 at 09:51, Adam Conrad wrote:
> >
> > > Package: libtool
> > > Version: 1.5-3
> > > Severity: serious
> > >
> > > libtool fails to build from source on all the buildds[1] due to a missing
> > > build-dep on texi2html.
> > >
> > libtool (and libtool1.4) *have* a build-dep on texi2html (and texinfo):
> >
> > Build-Depends-Indep: debhelper (>= 4.0), texi2html, texinfo
> > Build-Depends: debhelper (>= 4.0), file, g77 | fortran77-compiler, gcj
> > [!hppa !mips !mipsel]
> >
> > My reading of policy suggests that this is correct:
> >
> > `Build-Depends-Indep', `Build-Conflicts-Indep'
> > The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must
> > be satisfied when any of the following targets is invoked:
> > `build', `build-indep', `binary' and `binary-indep'.
> >
> > [1] If you make "build-arch" or "binary-arch", you need Build-Depends. If
> > you make "build-indep" or "binary-indep", you need Build-Depends and
> > Build-Depends-Indep. If you make "build" or "binary", you need both.
> >
> > texinfo and texi2html are used in the "build" target. As far as I can
> > tell this means that the buildd should be ensuring both Build-Depends
> > and Build-Depends-Indep are installed before running it.
>
> Other people have covered why this breaks. Here's the solution I use:
>
> Make your build target do nothing.
>
> That is, make build an empty target that does _not_ depend on
> build-arch and build-indep. Then make sure that binary-{arch,indep}
> will result in the right things getting run anyway.
>
> This a) preserves the desired effect of the time consuming arch-indep
> stuff not being run on the buildds, and b) actually works. While it's
> not strictly in accord with policy as written, it has the advantage of
> doing what policy expected to happen, and I've never seen a better
> idea.
>
> Ultimately we should either deprecate the build* targets, or make
> build-{arch,indep} mandatory and deprecate build.
What needs to happen to get this into policy?
Chris
signature.asc
Description: Digital signature
Re: Where are we now? (Was: Bits from the RM)
On Thu, Oct 02, 2003 at 03:13:23AM -0500, Chris Cheney wrote: > I still need to get KDE 3.1.4 into sid and stablized. I hope for it to > be ready to migrate into sarge by Oct 20 (including the 10 day wait > time). From what Colin Watson mentioned to me earlier today there are > some other packages that are holding KDE out as well so hopefully they > are resolved by then. Its taking me a bit longer than expected to get everything in order. I still need to fix some minor things in arts, kdelibs, kdebase, and kdemultimedia. Also there are lots of packages that need to be compiled on various archs. I emailed a full status update about KDE to the debian-qt-kde list for anyone interested. Chris signature.asc Description: Digital signature
Re: A case study of a new user turned off debian
On Mon, Nov 03, 2003 at 03:43:29PM -0600, Steve Greenland wrote: > On 03-Nov-03, 14:21 (CST), Erik Steffl <[EMAIL PROTECTED]> wrote: > > > is even worse than unstable> > > Oh, not this crap again. Or perhaps you're contending that I've not > gotten anything done at work in the last two years using my "useless" > Debian stable desktop. > > Hint: there's more to "useful" than running the latest version of > everything. Particularly for a sys admin, who I'd expect to be heavily > command line oriented, and who doesn't need the latest 3-d games or dvd > player[1]. It would be helpful if Debian could even be installed on machines newer than about 2 years old. Neither my KT400 based machine nor my i875P based machine could be installed using the standard Debian boot-floppies. I had to resort to using Knoppix with debootstrap. So no Debian stable really is not an option for a large portion of users. At least anyone who has a machine newer than when the kernel on b-f was last updated in Woody's case is kernel 2.4.18 from Feb 25 2002. Chris Cheney signature.asc Description: Digital signature
Re: A case study of a new user turned off debian
On Tue, Nov 04, 2003 at 12:47:30AM -0500, Greg Stark wrote: > So all it would take to make the tools handle this would be to somehow make > apt aware of more revisions of packages. They're all in the pool after all. > Short of making some king of humongous mega-Packages file with every revision > of every package -- which apt wouldn't scale up to anyways -- they're > currently unavailable to APT. Er no they are not all in the pool. The only packages in the pool are the current versions for stable/testing/unstable/experimental. There are also the few packages that haven't been completely compiled on all archs yet and so are still left in archive while this is being done. snapshot.debian.net has nearly every deb since 2002/06/04, but it is not an official debian repo afaik. Chris signature.asc Description: Digital signature
Re: A case study of a new user turned off debian
On Tue, Nov 04, 2003 at 08:17:06AM +, Andrew Suffield wrote: > I challenge the assertion that this affects a large portion of users. > > In the past few months, I've installed woody on roughly 30-40 > different types of box, all aged 0-3 years, and only one was > unsupported by woody (and that was freaky new apple kit). > > I think you have unusual hardware. Neither are that unusual. I suppose it may have been a little highend for some when I first bought them, but now they are relatively cheap, an AthlonXP Via KT400 based motherboard now is as cheap as $42 USD and the P4 i865/i875 chipset series is as cheap as $62 USD. Perhaps all of your 0-3 year old systems had older chipset logic in them, or perhaps truly new systems just aren't common in your country. Via KT400 was released 16 Aug 2002 and the i865/i875 line was released 14 Apr 2003. Note that nearly all P4 systems with the 800MHz FSB use the i865/i875 chipsets. I refuse to use nvidia products, but I somehow doubt that boards based on their nforce2 chipset work properly either. Regardless updating boot-floppies when new kernels come out would be a good idea so that newbies with recent machines can still use Debian. Chris Release Dates: Intel - i84510 Sept 2001 i87514 Apr 2003 i86521 May 2003 Nvidia -- nforce 4 June 2001 nforce2 16 July 2002 Via --- KT266 20 Sept 2000 KT266A 3 Sept 2001 KT333 20 Feb 2002 KT400 16 Aug 2002 KT400A 10 Mar 2003 KT600 18 Jun 2003 signature.asc Description: Digital signature
Re: Bug#219582: ITP: linux -- Linux 2.4 kernel
On Sat, Nov 08, 2003 at 11:39:38AM +1100, Brian May wrote: > On Fri, Nov 07, 2003 at 08:13:18PM +0100, Santiago Vila wrote: > > At least, the ability to do > > > > apt-get source linux > > > > as it should always have been. > > > > > > I think it's time we put an end to this euphemism called "the kernel" > > and start calling it by its proper name (if we refer to Linux, that is). > > apt-get source kernel-source-2.4.22 > ??? Good point, the kernel source probably should be renamed to linux-source-2.4.22 since people want to support hurd and the various BSDs under Debian as well. Probably any package referencing kernel needs to be changed to linux instead. Chris signature.asc Description: Digital signature
Re: gimp1.2: gimp package suggest non-free software
On Thu, Nov 13, 2003 at 01:12:10AM +0100, Henning Makholm wrote: > Scripsit Brian May <[EMAIL PROTECTED]> > > > Anyway, on the given topic, are "reverse-suggests" possible? > > Quoth debian-policy, section 7.2: > > |Enhances > | This field is similar to Suggests but works in the opposite > | direction. It is used to declare that a package can enhance the > | functionality of another package. Except for the fact that no tool supports Enhances... (or has that changed?) Chris signature.asc Description: Digital signature
Re: MIPS port backlog, autobuilder machines and some arrogance
On Fri, Nov 14, 2003 at 02:55:09PM +0100, Wouter Verhelst wrote: > Op vr 14-11-2003, om 11:34 schreef Ingo Juergensmann: > [...] > > As a result and a sort of protest, I´ll stopped my m68k buildd, because I > > don´t know m68k that much to be of any help for this port anymore. Therefore > > my m68k isn´t needed anymore as my offered mips machine isn´t needed for the > > mips port or the Debian project at all. > > Ingo, > > I can understand why you're upset, but please do try not to make one > port suffer for the actions of the people responsible for another port. > The help arrakis has provided over the years has always been > appreciated, and will be for as long as you provide the access; it would > be a shame if this would be discontinued because of a difference in > opinion you have with Ryan regarding the way autobuilding for the mips > architecture should be handled. So why does Ryan have the authority to reject more buildd's when he obviously is overburdened to the point he doesn't respond to emails (see Branden Robinson's post as an example). From an untrained eye the mips buildd's seem to be building packages more or less fine just that they were lagged by the human behind them. One example is kdelibs which wasn't built for nearly a month due to what should have been a Dep-Wait on a fixed libXrender, which was uploaded the same day mips attempted to build kdelibs. Chris signature.asc Description: Digital signature
Re: MIPS port backlog, autobuilder machines and some arrogance
Another point is do we really want an arch/port to be maintained by only one person? IMHO there should be at least two people capable and actually running the buildds for each arch, possibly more when they are too busy with other things as appears the case with Ryan. Chris signature.asc Description: Digital signature
Any Progress?
I was wondering if there is any progress in getting the servers back to normal. I noticed that http://qa.debian.org/developer.php still isn't updating. Also how long until the buildd's are back online? I only see 3 archs that have online buildds right now. It also appears master's email is broken. Bugs I tried closing in one email yesterday (via multiple [EMAIL PROTECTED]) have yet to be closed and an email I sent to debian-qt-kde still hasn't appeared after 2 hours. Also bugs I tried to close individually about 1 hour ago have yet to be closed as well. Its been 3 weeks now since Debian was compromised, hopefully it won't take too much longer for Debian to return to normal... Thanks, Chris Cheney signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 11:42:25AM -0600, Gunnar Wolf wrote: > Worse yet - after demanding that, we probably will rewrite their > .desktop files - We will still (I hope) strive to provide menus > consistent with our way of doing things. One of the main roles of the > maintainers of a distribution is to handle interaction between each > individual package and the rest of the collection - this involves > sorting out how menus will be presented. All that would do is make it consitently different from all other distributions. Assuming that they listed the proper Categories in their "Categories:" section all that would be needed, if we wanted to be different from other dists, is tweaking of how to break out the menu hierarchy. It would not involve any modification of the .desktop files themselves. See section A. http://www.freedesktop.org/standards/menu-spec/menu-spec-0.8.html Chris Cheney signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: > On Tue, 9 Dec 2003, Henning Makholm wrote: > > Scripsit Bruce Sass <[EMAIL PROTECTED]> > > > On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: > > > > > > In which format shall application packages store > > > > their menu information. > > > > > It doesn't matter, > > > > If you don't think the problem being discussed matters, why are you > > participating in the discussion? > > The "problem" is real, the format used to convey the data is > immaterial. > > > > the question should be, "what requires more work: adding features to > > > the existing menu system, or changing the entire menu system." > > > > Is there a difference? The changes being contemplated consist in > > adding features, and any addition of features constitute a change. > > Yes. relatively small change vs. rewriting almost from scratch NIH. > > > > Users and developers propose following the > > > > freedesktop standard and using this. > > > > > Users and developers are also resisting the proposal. > > > > With few or no actual arguments about what would go bad. > > The pain is not worth the gain... why should all the menu consumers > need to redo their menu handling so two of them can have a slightly > easier time of it. Or just let the Gnome and KDE people who want this do the rewrite for the others. > > > > How is this logical? How does the freedesktop standard not "gain" us > > > > features? > > > > > Because nobody but KDE and Gnome use those features and they > > > already support .desktop files. > > > > Yes, but that does not buy KDE and Gnome users anything unless the > > .desktop files are in the .debs for the applications they use. We're > > discussions how to allow the .debs to contain them without duplication > > of information and needless redundancy. > > Ok. How about doing it so the vast majority of menu consumers are not > stuck with a needless rewrite. See above... > > > > freedesktop entry features > debian menu file features > > > > > True, but everyone except KDE and Gnome will toss out the freedesktop > > > features. Processing bloated .desktop files just to toss the > > > results is a waste of resources. > > > > The fraction of Debian users who use KDE and Gnome is probably less > > than 90%, but I don't believe that it is small enough that it makes > > sense to oppose on principle their getting the information they want. > > All users should be able to get what they want, including those who > don't want KDE or Gnome... saddling them with bloated .desktop files > does not achieve that. .desktop files are not bloated... period. They include i18n which for you is bloat since you obviously can communicate in English. As I mentioned further down in this message Konqueror only uses 159 bytes when all i18n is stripped from it. I see many debian menu files that are larger than this and they don't contain i18n either. > > > Nobody benefits from the transition... not even KDE or Gnome, since > > > they already support the features the freedesktop standard brings to > > > the table. > > > > Having a .desktop infrastructure is worth nothing if you dont have the > > data it works with. KDE and Gnome users would certainly benefit from > > having .desktop files in the .debs of the packages they use. > > Yes, but they would benefit in the same way if the KDE and Gnome > specific bits were an addendum to the main menu data entries. > > Only KDE and Gnome users stand to benefit, so they should be the ones > with the added burden. If several KDE and Gnome developers got together and rewrote the menu-methods for the various WM's would that satisfy you? > > > I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce > > > and mwm installed... processing the menues takes too much time and > > > resources as it is, and you want to use up more, for what gain? > > > > Just how much more time and resources would it take to convert > > .desktop files to Debian menu definitions? How often does it have to > > be done? > > 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; > what percentage of resources that takes depends on the system... it > may be a drop in the bucket for KDE and Gnome users, who are likely to > have very capable machines, but what about those who don't have the > resources to run KDE or Gnome---why should they be stuck with > processing useless stuff they likely can't afford and obviously don't > want? The entire menu hierarchy is regenerated everytime a package > containing a menu entry is installed or removed. I call bullshit on this one. desktop files with no i18n are not several thousand bytes _pre_entry_. And the fact that those other WM's don't support should be considered a bug not a feature... For example the Konqueror .desktop file is 159 bytes with no i18n or 2234 with it. If as we suggested earlier the Debian menu format gain i18n support then it would be just as big as .desktop (probably actually si
Re: Any Progress?
On Fri, Dec 12, 2003 at 10:36:30PM +, Colin Watson wrote: > On Fri, Dec 12, 2003 at 03:35:53PM -0600, Chris Cheney wrote: > > It also appears master's email is broken. Bugs I tried closing in one > > email yesterday (via multiple [EMAIL PROTECTED]) have yet to be closed and > > an email I sent to debian-qt-kde still hasn't appeared after 2 hours. > > Also bugs I tried to close individually about 1 hour ago have yet to > > be closed as well. > > Please cc [EMAIL PROTECTED] about bugs.debian.org problems in future. > > Can you supply some message-ids or subject lines or something so that we > can investigate? master's e-mail doesn't appear to be generally broken. > I wonder, though, if all five (!) MXs are doing the right thing. Message-ID: <[EMAIL PROTECTED]> The other bug reports from earlier today seem to have been processed but took an hour to do so. Actually from looking at the timestamp they were processed 1min after I sent my previous email, heh. The message to debian-qt-kde that was clogged up by murphy for ~ 2hrs was: Message-ID: <[EMAIL PROTECTED]> Thanks, Chris signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 12:28:29PM +0800, Cameron Patrick wrote: > On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote: > | Cameron Patrick wrote: > | > | > On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: > | > > | > | > Because you gain *nothing* > | > | > | > | Are you claiming that everyone who says that .desktop has technical > | > | advantages is a liar? These features actually do not exist in the > | > | desktop format? (It may be so; I have no firsthand information, but it > | > | does sound far out). > | > > | > Most of the advantages of .desktop that I am aware of are currently > | > vapourware - i.e. they're in the specs on the freedesktop.org site, but > | > not yet implemented in KDE and Gnome. > | > | This is not true. Almost all features are being used in current KDE and to > | some degree by current GNOME. Could you please give examples? > > The Categories= field (to place .desktop files into menu hierarchies) is > AFAIK not used at all by KDE, although I think Gnome may support it. > The freedesktop 'menu' standard (where sub-menus can be generated from > the categories in the .desktop files, and which also claims to allow > "legacy" menus to be merged with the new standard) doesn't seem to have > been adopted yet by anyone. The worst part, though, is that currently > both KDE and Gnome store their .desktop files in different places, so > that a .desktop that is available to KDE (and placed in /usr/lib/applnk) > won't automatically appear in the Gnome menu, which looks in > /usr/lib/applications. I presume that these things are being worked on > in later releases of KDE and Gnome, but I don't know where to look for > the current status of their adoption of the freedesktop.org standards. The above statements are probably true of KDE 3.1 since it doesn't use the proper /usr/share/applications layout. KDE 3.2 which is due to be released in about a month does use it. The location Gnome uses is correct. > I have also noticed what might be considered as 'abuse' of these > standards, presumably due to poor implementation of some fields. For > example, /usr/share/applications/epiphany.desktop lists its Name as "Web > Browser"; it should more correctly list its name as "Epiphany" and have > a GenericName field containing "Web Browser". I've already reported that, several months ago, to some Gnome people in #debian-devel, hopefully it will be fixed soon. Chris signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 06:33:52PM -0500, Daniel Burrows wrote: > On Fri, Dec 12, 2003 at 04:11:08PM -0600, Chris Cheney <[EMAIL PROTECTED]> > was heard to say: > > All that would do is make it consitently different from all other > > distributions. Assuming that they listed the proper Categories in their > > > "Categories:" section all that would be needed, if we wanted to be > ^ > > Isn't that a rather large assumption? If they aren't in the proper categories as listed by the standard it should be treated as any other bug and be corrected. That won't be the common case, and we can just write the convertor to look for the standardized categories. Chris signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 05:47:17PM -0700, Bruce Sass wrote: > On Fri, 12 Dec 2003, Chris Cheney wrote: > > On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: > <...> > > .desktop files are not bloated... period. They include i18n which for > > you is bloat since you obviously can communicate in English. > > "not bloated... period", yet you admit the translations are bloat for > someone who doesn't need them. Can you also accept the X-KDE-* stuff > is bloat for every menu data consumer except KDE (ditto for Gnome > specials), and that in general freedesktop features are bloat for > everyone who doesn't support the freedesktop standard. Bloat is relative, since i18n is needed by a large amount of people, certainly more than need english it is not really bloat. Certainly it isn't bloat for the 5Bil+ people whose language isn't english. Something you might determine is a critical feature someone else might consider bloat. Yes, X-KDE-* could be considered to be bloat by some people. However, the same people who have systems fast enough to actually run Gnome or KDE also have large enough hard drives that it shouldn't even be a consideration. Across all desktop files in the archive that probably amounts to less than 100KB of additional space. Bitching about a loss of 100KB when the same packages overall take 500MB+ is very petty. And no I do not think that the freedesktop standard overall is bloat. > > As I mentioned further down in this message Konqueror only uses 159 > > bytes when all i18n is stripped from it. I see many debian menu > > files that are larger than this and they don't contain i18n either. > > I suspect those files contain more than one menu entry; KDE has a file > per entry, menu uses a file per package which contain multiple menu > entries. Yes that is true, so I went and got the konqueror menu file to compare. Just the one entry for the file browser which is equivalent to the .desktop file is bigger than the .desktop file without its i18n support. And add to that the fact that the .menu description is shorter which further disproves the point that .desktop files are larger. .desktop - 159 bytes [Desktop Entry] Encoding=UTF-8 Type=Application Exec=kfmclient openProfile webbrowsing Icon=konqueror DocPath=konqueror/index.html Name=Konqueror Web Browser .menu - 168 bytes ?package(konqueror):\ needs=X11\ section=Apps/Net\ hints="KDE,Web browsers"\ kderemove="y"\ title="Konqueror"\ command="/usr/bin/konqueror --profile webbrowsing" > > If several KDE and Gnome developers got together and rewrote the > > menu-methods for the various WM's would that satisfy you? > > No, because it doesn't address the primary concern of (say) a Fluxbox > user needing to process the KDE, Gnome, and freedesktop stuff which > they don't have a use for. I contend that the processing the time difference would not be sufficient to tell the difference over extracting and installing packages on the system. And the only time menus get rebuilt normally is when you are installing new packages. Systems old enough to worry about this also typically don't have hundreds of menu files to deal with as well since their hd's are too small. As someone else stated regenerating all the menu files included with KDE (which is several hundred iirc) takes less than 10s on an Athlon 600, which is about a 5 year old system. > > > 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; > > > what percentage of resources that takes depends on the system... it > > > may be a drop in the bucket for KDE and Gnome users, who are likely to > > > have very capable machines, but what about those who don't have the > > > resources to run KDE or Gnome---why should they be stuck with > > > processing useless stuff they likely can't afford and obviously don't > > > want? The entire menu hierarchy is regenerated everytime a package > > > containing a menu entry is installed or removed. > > > > I call bullshit on this one. desktop files with no i18n are not several > > thousand bytes _pre_entry_. And the fact that those other WM's don't > > support should be considered a bug not a feature... For example the > > Konqueror .desktop file is 159 bytes with no i18n or 2234 with it. If as > > we suggested earlier the Debian menu format gain i18n support then it > > would be just as big as .desktop (probably actually since Debian has > > very limited i18n support). > > Ok, the .desktop file sizes are typically between 1 and 2K---but you > don't have to look too hard to find 3 or 4K .desktop files, and some > of the (
Re: Any Progress?
On Sun, Dec 14, 2003 at 12:12:29AM -0500, Clint Adams wrote: > > Please cc [EMAIL PROTECTED] about bugs.debian.org problems in future. > > > > Can you supply some message-ids or subject lines or something so that we > > can investigate? master's e-mail doesn't appear to be generally broken. > > I wonder, though, if all five (!) MXs are doing the right thing. > > I've had at least 5 BTS mails bounced back to me, and master continues > to reject with '451 rejected: temporarily unable to verify sender > address'. > > I suspect that this message will never reach [EMAIL PROTECTED] I haven't noticed it bouncing but it has yet to process the bug email I mentioned in my other post. Also, I have not heard back from anyone as to why that might have happened. With the BTS being broken (or at least appears to be) working on packages becomes a lot more of a pita. You have to fix the bugs, close them, and then go back later and make sure they actually got closed, which isn't happening. Add to that the fact that the developer.php summary page is still fubar, I think I'll take a vacation from Debian until things are back to normal. Chris signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Mon, Dec 15, 2003 at 01:54:13PM +0800, Cameron Patrick wrote: > On Mon, Dec 15, 2003 at 04:07:56AM +, Scott James Remnant wrote: > > | Only GNOME applications should be in the GNOME Applications menu. > > Why?! Yea, I thought that was somewhat odd. The only reason the non KDE items are better integrated into the current KDE menu is due to technical limitations. I expect to be able to do it better when KDE converts fully to the standard (KDE 3.2) like Gnome currently has. Chris signature.asc Description: Digital signature
Re: Any Progress?
On Mon, Dec 15, 2003 at 11:21:44AM +, Colin Watson wrote: > On Sun, Dec 14, 2003 at 10:43:02PM -0600, Chris Cheney wrote: > > On Sun, Dec 14, 2003 at 12:12:29AM -0500, Clint Adams wrote: > > > > Can you supply some message-ids or subject lines or something so that we > > > > can investigate? master's e-mail doesn't appear to be generally broken. > > > > I wonder, though, if all five (!) MXs are doing the right thing. > > > > > > I've had at least 5 BTS mails bounced back to me, and master continues > > > to reject with '451 rejected: temporarily unable to verify sender > > > address'. > > > > > > I suspect that this message will never reach [EMAIL PROTECTED] > > > > I haven't noticed it bouncing but it has yet to process the bug email I > > mentioned in my other post. Also, I have not heard back from anyone as > > to why that might have happened. > > Clint's problem turned out to be due to an unreadable home directory on > master. Your case is different: it appears that the mail you reported > (<[EMAIL PROTECTED]>) was erroneously caught by our spam > filters. I've reinjected it by hand and the bugs are now closed. > > Content analysis details: (4.3 points, 4.0 required) > > pts rule name description > -- -- > 4.3 SORTED_RECIPS Recipient list is sorted by address > > Note that this has nothing to do with the recent compromise. I've > dropped the SORTED_RECIPS score to 3.8 to try to reduce false positives > here; I hope that doesn't result in too much more mass spam. Thanks for the quick response and remedy. > > Add to that the fact that the developer.php summary page is still > > fubar, I think I'll take a vacation from Debian until things are back > > to normal. > > I think things are fairly normal right now to be honest, but if you do > take a vacation at least please make sure somebody uploads kdebase. :) > > I guess one of the QA group will have a look at developer.php soon. I guess I can live without having up to date information on the qa page for now, it does make life much easier though. Now that at the bug reports aren't being lost anymore I can upload without having to constantly double check myself. :) Thanks! Chris signature.asc Description: Digital signature
Re: How to transition to G++ 3.2 wthout any breakage
On Sun, Aug 18, 2002 at 06:09:18PM +0200, Luca Barbieri wrote: > > Of course there is. You upload new versions of the gcc 2.95 packages, > > and you make the new gcc 3.2 packages conflict with the old ones. > > Nothing is broken in that case. > False. > Users will no longer get updated version of any C++ package unless they > manually remove/recompile any package depending on the old libraries > which is not yet recompiled or is not in Debian. > > For example, how about calc.cx KDE 3.0 packages that are obviously > necessary for any KDE user? I don't see any mention of GCC 3.2 on their > text file so I assume that they aren't ported. Why is KDE 3.0 obviously necessary for any KDE user? KDE 2.2.2 still works fine but will probably suffer from the same issue. However, I will rebuild against gcc 3.2 as soon as libfam/libqt gets rebuilt against it. Chris
Re: imlib-linked-with-libpng3
Why not simply make a imlib1p that conflicts with old imlib1 and rebuild the remaining 11 sources that still use imlib1 with old libpng2? There are fewer that would cause trouble in that batch, afaict only: chameleon, ebview, endeavour, pixelize, vertex. chameleon - dead upstream. (no website anymore) ebview- no idea since its japanese. endeavour - might work with gtk2? upstream is alive. pixelize - dead upstream. (last release 2000-01-17) vertex- might work with gtk2? upstream is alive. kdegraphics requires being able to link to imlib with png3 to work due to png symbol collisions. Why aren't we working to get rid of libpng2 anyway, libpng3 isn't even current anymore. Sources --- libpng2- 134 libpng3- 23 libpng12-0 - 185 Of the ones linked to libpng2 about 20 of those are KDE related and will go away soon (all associated packages have RC bugs). Many of the others seem to link to libpng2 only due to maintainers not updating their build-depends, like zsnes. Chris
Re: imlib-linked-with-libpng3
By the way RedHat does it is as follows: imlib-1.9.13-12.i386.rpm /usr/lib libgdk_imlib.so.1 libgdk_imlib.so.1.9.13 libimlib-bmp.so libimlib-gif.so libimlib-jpeg.so libimlib-png.so libimlib-ppm.so libimlib-ps.so libImlib.so.11 libImlib.so.11.0.0 libimlib-tiff.so libimlib-xpm.so ldd libImlib.so.11 -- libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40035000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40052000) libungif.so.4 => /usr/lib/libungif.so.4 (0x40095000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4009c000)<- *** libz.so.1 => /lib/libz.so.1 (0x400c4000) libm.so.6 => /lib/libm.so.6 (0x400d1000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x400f3000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400fb000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4011) libc.so.6 => /lib/libc.so.6 (0x4011d000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4022d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) libdl.so.2 => /lib/libdl.so.2 (0x402e8000) Perhaps it would be a good idea for debian to rebuild against newer libraries... since otherwise we will always have these old libs in our archive and we also knowingly become incompatible with other dists. Chris
Re: imlib-linked-with-libpng3
On Fri, Apr 18, 2003 at 08:43:45PM -0400, Steve M. Robbins wrote: > Imlib is more-or-less dormant upstream. However, in late August, I > was under the impression that upstream imlib was going to release a > new version (with new SONAME) that would be linked with libpng3. In I forgot to comment on this part. Its not upstreams place to deal with what a particular user of the software decides to link stuff with. If you break ABI that is no reason to mess with the ABI numbering which is what SOVER's are for. This was already discussed to death in numerous other threads the one that most readily comes to mind was the gcc c102 thread. In Debian's case if you break ABI you are supposed to add some sort of differenation to the package name, such as imlib1foo and make it conflict with the old version. From what I am able to tell, other dists just rebuild against the current versions of libraries and don't bother with renaming the packages themselves. Chris
Re: plagiarism of reiserfs by Debian
On Sat, Apr 19, 2003 at 04:25:57PM -0600, Andreas Dilger wrote: > On Apr 19, 2003 16:55 -0400, Ben Collins wrote: > > > all that was removed was *code* that gets compiled. If the maintainer > > > cannot arbitrarily change any code he wants, then it is not clear that > > > the program is DFSG-free. > > > > Amen. Making part of the code immutable is not what I call free > > software. What if I want to use parts of the code and I respect the > > copyright and license...does that mean I also have to take this part of > > the code and output the credits? What if environment doesn't provide a > > way to output the credits. What if I am implementing the reiser tools on > > an embedded system that will never show any such output? > > I'm sure all the FSF/Debian folks would be thrilled if someone changed the > code in [x]emacs to not output anything about the GPL at startup, or if vim > didn't include any info about helping Ugandan orphans. First of all emacs is pure bloat so who cares what it does... Vim has one line about Ugandan orphans at startup, until now I didn't even notice it was there. If had been pages of crap like what is spewed from mkfs.reiserfs it would have probably been removed as well, unless it was against Vim's license, which happens not to be GPL. As far as I can tell if it annoyed someone enough it is legal under Vim's license to remove the Uganda message as well, they only require the license text itself to remain with the application. A GPLv3 allowing spamware would be very annoying, I hope it doesn't happen. If anything this stupid reiserfs spamware should be spewed before the program runs, not after, so that the user can see what actually occured without having to scroll back up, which depending on their console type might be difficult. Chris
Re: plagiarism of reiserfs by Debian
Of course as you already know emacs includes so many thing unrelated to editing that anyone using it has already decided they don't mind the bloat. *OT* Really is there any argument that a psychoanalysis program in an editor is not bloat? By the way emacs21 takes 50MB to install (vim takes 15MB), and yes a full KDE install takes more at around 254MB to install but it could be argued it provides more functionality. ;) Of course KDE can also be seen as bloat to people enjoying using command line tools or flipping the switches on their altair. ;) *OT* The point I was trying to make was that adding bloat for no good reason at all, in this case over a screenfull of advertising to a console util harms its usability. Chris
Re: plagiarism of reiserfs by Debian
I followed Release Managers request on how to deal with the libvorbis mess, if you have a problem with how it was dealt with bring it up on irc. You should know this already but a message was sent out a week in advance to the libvorbis breakage occuring so that maintainers would about it. And no the general consensus is not for a library to conflict with every package that built against an older version (I don't recall if you suggested that or if it was someone else). Thanks, Chris
Re: plagiarism of reiserfs by Debian
On Mon, Apr 21, 2003 at 09:40:50AM +0400, Hans Reiser wrote: > Maybe, but not very many people run mkreiserfs frequently. For most > users, mkreiserfs is performed once on installation, or close enough to > not matter a lot. What about the fact that most installers don't even show the output of mkfs.*? I think the primary reason debian still does is because it hasn't finished its gui installer but this will likely be done for d-i eventually. Chris
Re: libpng3 upgrade will remove kde development packages
On Thu, Apr 24, 2003 at 12:17:46AM +0200, Josselin Mouette wrote: > Le mer 23/04/2003 à 22:23, Josh Metzler a écrit : > > > Shuttle:/home/josh# apt-get -s install libpng3 > > Reading Package Lists... Done > > Building Dependency Tree... Done > > The following extra packages will be installed: > > libpng12-0 > > The following packages will be REMOVED: > > kdelibs4-dev kdesdk kspy libarts1-dev libartsc0-dev libpng12-0-dev > > libqt3-mt-dev > > The following held packages will be changed: > > libpng12-0 libpng3 > > This should be fine if you tell apt-get to install libpng12-dev > explicitly. > BTW, shouldn't APT deal with this case (conflicts/replaces/provides) > automatically ? It might have something to do with him having libpng12-0 libpng3 set to hold? When I attempt to install kdelibs4-dev here it seems to work correctly: singularity:~# apt-get install kdelibs4-dev Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: libart-2.0-dev libarts1 libarts1-dev libartsc0 libartsc0-dev libasound2-dev libaudio-dev libaudiofile-dev libcupsys2 libcupsys2-dev libfam-dev libfreetype6-dev libglib2.0-dev libjpeg62-dev liblcms1-dev libmad0-dev libmng-dev libogg-dev libpcre3-dev libpng12-dev libqt3-headers libqt3-mt-dev libvorbis-dev pkg-config qt3-dev-tools xlibmesa-gl-dev xlibmesa-glu-dev xlibs-dev zlib1g-dev The following NEW packages will be installed: kdelibs4-dev libart-2.0-dev libarts1-dev libartsc0-dev libasound2-dev libaudio-dev libaudiofile-dev libcupsys2-dev libfam-dev libfreetype6-dev libglib2.0-dev libjpeg62-dev liblcms1-dev libmad0-dev libmng-dev libogg-dev libpcre3-dev libpng12-dev libqt3-headers libqt3-mt-dev libvorbis-dev pkg-config qt3-dev-tools xlibmesa-gl-dev xlibmesa-glu-dev xlibs-dev zlib1g-dev The following held packages will be changed: libarts1 libartsc0 3 packages upgraded, 27 newly installed, 0 to remove and 7 not upgraded. Need to get 11.7MB of archives. After unpacking 42.8MB will be used.
Re: libpng clarification
On Fri, Apr 25, 2003 at 02:02:22AM +0200, Josselin Mouette wrote: > Q: Why don't we just say goodbye to binary-compatibility with other > distros on those few corner cases ? > A: I'm not against that, but some people in the project seem to be. > Anyway, this is certainly not a move we can make without thinking. As far as I could tell the last time I looked at RedHat they have already switched to using libpng12 for most things. For example imlib, I haven't looked at their gnome but with imlib using libpng12 it would seem it would have to be using libpng12 as well. So unless I am mistaken we are only maintaining binary-compatibility with old versions of Debian not other distributions (or at least not RedHat). Chris
Re: libpng clarification
On Thu, Apr 24, 2003 at 09:16:34PM -0500, Steve Langasek wrote: > Wrong. It was Red Hat who *instigated* the change in library names > upstream to allow the devel packages to be installed simultaneously, > because they have no intention of trying to recompile GNOME 1 against a > different libpng. So gnome doesn't use imlib (in Debian at least it seems to), or did I somehow miss why it appears RedHat only has one version of imlib, which is the version compiled against libpng12? Chris
Re: pilot-link in Sid and Sarge: Much bigger question
Debian sid is roughly equal to most other distributions official releases. One of the main reasons that Debian stable and testing are always behind other distributions is due to the fact Debian requires much more out of the packages, by requiring them to work on all architectures and without major bugs. In some cases they lag even in Debian unstable due to the fact that the upstream doesn't properly test their releases and integrate bug fixes, for example XFree86. I do think that having an automated check for packages being out of date with upstream would be nice though. Perhaps if policy required the watch file be present for packages then qa.debian.org could add checks for them to the developer and packages pages. That would make it much easier for maintainers to see when packages are out of date and either update their own packages or ping the respective maintainer to see if they are still around. Chris
Re: pilot-link in Sid and Sarge: Much bigger question
On Fri, Apr 25, 2003 at 03:27:57PM -0500, David Krider wrote: > I know, I know. I've heard lots of people talk about how great it is, > but, as far as I know, the bitmapped fonts under KDE in Sid are still > messed up, and that's a show stopper for me. Hopefully this will be resolved eventually or else it will probably bite the other distributions you run. It appears it is a fontconfig 2.2 bug/feature of some sort. It seems to refuse to even cache many bitmap fonts. Also, Qt currently has a bug that allows it to still see fonts that XF86Config-4 knows about but it can't use them, so you may see some strange font substitutions. The new Qt can't go into sid yet due to some dlopen bug in glibc 2.3.1, so it is having to wait on glibc 2.3.2 to be uploaded first. If you just use truetype fonts instead though it should work fine. Chris
Re: i386 compatibility & libstdc++
On Fri, Apr 25, 2003 at 05:06:00PM +0200, Arnd Bergmann wrote: > If we really want to split i386 in 'compatible' and 'fast', the i686 border > makes sense because users who care about speed probably bought the machine > during the last two years and those should be i686 compatible. i686 has been common for 6 years now (1997 P2/K6), so its hardly just in the past two years. ;) I agree the split should be at the i686 border assuming this doesn't harm athlon systems. Release Dates (i686+) - Pentium Pro - Nov 1995 Pentium II - Feb 1997 Pentium III - Feb 1999 Pentium IV - Nov 2000 K6 - Apr 1997 Athlon - Aug 1999 Chris
Re: libpng clarification
On Fri, Apr 25, 2003 at 10:15:25AM +0200, Josselin Mouette wrote: > Le ven 25/04/2003 à 04:46, Chris Cheney a écrit : > > On Thu, Apr 24, 2003 at 09:16:34PM -0500, Steve Langasek wrote: > > > Wrong. It was Red Hat who *instigated* the change in library names > > > upstream to allow the devel packages to be installed simultaneously, > > > because they have no intention of trying to recompile GNOME 1 against a > > > different libpng. > > > > So gnome doesn't use imlib (in Debian at least it seems to), or did I > > somehow miss why it appears RedHat only has one version of imlib, > > which is the version compiled against libpng12? > > Gnome doesn't use imlib, but it certainly uses gdk-imlib. You can try a > little apt-cache showpkg gdk-imlib1 to convince yourself. Package: gdk-imlib1 Priority: optional Section: oldlibs Installed-Size: 276 Maintainer: Steve M. Robbins <[EMAIL PROTECTED]> Architecture: i386 Source: imlib+png2 ... gdk-imlib is part of imlib which isn't split on RedHat afaict so I suppose the answer is RedHat doesn't support Gnome 1.x anymore. I don't know for certain because I don't actually run RedHat, I have just been extracting rpm's to look at how they packaged imlib. Chris
Re: i386 compatibility & libstdc++
On Sat, Apr 26, 2003 at 09:36:56AM +0800, Cameron Patrick wrote: > What about the Via C3? That was introduced not too long ago, runs > moderately quickly (~1GHz) with low power consumption, but IIRC doesn't > support the i686 instruction set. The issue with this appears to be a gcc bug with respect to compiling for i686: http://marc.theaimsgroup.com/?l=linux-kernel&m=104263370505476&w=2 Also, as I understand it the new C3 Nehemiah core now has the cmov instruction. Chris
Re: i386 compatibility & libstdc++
On Sat, Apr 26, 2003 at 03:41:31AM +0200, Josselin Mouette wrote: > Le sam 26/04/2003 à 03:15, Chris Cheney a écrit : > > i686 has been common for 6 years now (1997 P2/K6), so its hardly just in > > the past two years. ;) > > Err, k6 is not a 686 as to my knowledge. Between this post "http://gcc.gnu.org/ml/gcc/2001-06/msg01180.html"; and the post I copied with respect to Via C3 it seems that K6 might actually work as i686 if upstream GCC fixed their cmov "bug". > > I agree the split should be at the i686 border > > assuming this doesn't harm athlon systems. > > This would be a good border, but we would need to provide a much larger > subset of packages (if not all the distro) for 386/486/586, while we > would only need to provide what can run on a 386 if we set the limit > between 386 and 486. The last true i586 based cpu I know of was the Mobile Pentium MMX 300 which was released around Jan 1998. If we are going to make a break at all it should be at the arch that makes the best speed increase for modern systems (Athlon/P4) imho, whichever that happens to be. Of course to use i686 we would need to convince GCC to fix that cmov bug which would keep AMD K6(?) and Via C3 from working properly on i686. Chris
Re: i386 compatibility & libstdc++
On Sat, Apr 26, 2003 at 05:06:56AM +0200, Arnd Bergmann wrote: > No, if you disable cmov on i686, that won't make Athlons and P4s faster > than simply using -march=i586. If all packages are available for i386, > the C3 and K6 users just won't be able to use the fast packages but can > still work. If we cripple Debian on i386 by leaving out some of the > packages, the border needs to be lower than i686, e.g. i486 or i586-mmx. The only improvement from i586 to i686 was the cmov instruction(?) that is supposedly not even mandatory to support to be compliant with the i686 arch? I thought it had a lot more improvements than just that one instruction... Chris
