Some advices about debconf i18n (was: Re: Help needed with debconf)
A bit out of topic and not helpful for your main problem, but please find a little advice about the templates themselves... First of all, please make them translatable. man po-debconf will give you the needed information, but it's basically a matter of prepending Choices and Description with "_" Install the po-debconf package and then run "debconf-gettextize". This will create the needed files in debian/po as well as slightly modify your templates file. Then, before uploading your package, please give translators a chance to get the translations in by posting a request for translations in debian-i18n@lists.debian.org with the debian/po/templates.pot file attached. Then, just leave translators and translation teams a few days (about one week) for working on it (some teams have a quality process which involves reviewing the translations and takes some time). You will probably receive some PO files such as fr.po (that one you will receive..:-))), nl.po, ja.po and so on Just put them in debian/po and let dh_installdebconf do the job of building the translated templates. > Template: ttf-arphic-uming/variant > Type: select > Choices: Unicode, MBE, both _Choices: Unicode, MBE, Both (the capital letter will give a better consistency to the presentation) > Default: Unicode No initial "_" here as this is not translatable. debconf-gettextize will add one : just remove it. > Description: Which font variant do you want to install? The Debconf Templates Style Guide, which is now part of the developers reference suggest avoiding questions for select and string templates: _Description: Font variant to install: (note the colon.) Following this would give Debian debconf templates more general consistency. > This font contains bopomofo extended glyphs, which are used to > annotate chinese glyphs to show how the characters should be > pronounced. These bopomofo extended glyphs are used for some > minority languages, like Taiwanese and Hakka. They are mainly ^ Remove the trailing space here otherwise the template will have two spaces > used in Taiwan. > . > There are two variants of these bopomofo > extended glyphs in use, one which conformes to the Unicode standard, > and one, called Modern Bopomofo Extensions (MBE), which aims to be > easier to read and write. > . > The Unicode variant also contains the MBE variants encoded as TTF > stylistic alternatives (SALT). As only few programs can support > this feature, users who prefer to use the MBE glyphs should install > the MBE variant instead of the Unicode one. > . > If you don't know what I'm talking about or don't intend to use > those glyphs at all, choose Unicode. Do no use first person in templates. As this is discouraged in init scripts, this is discouraged as well in debconf templates. I would rephrase the last sentence to something like 'If in doubt, please select "Unicode".' --
Re: RFC: common database policy/infrastracture
On Wed, 15 Dec 2004, sean finney wrote:
On Mon, Dec 13, 2004 at 08:36:19PM +0100, Andreas Tille wrote:
Do you have any hint for me how to help here and according to my
previous mail on debian-devel how can I obtain debconf settings
for the specific package ( db_get gnumed/pgsql/admin-pass)
because I did not understand how you planned to do this.
there's a file in /etc/dbconfig-common per-package that has these
settings in a shell script include format, so you could essentially
do something like
. /etc/dbconfig-common/$package.config
this is to work with the "debconf is not a registry (tm)" philosophy.
this config file is also sourced in all the maintainer scripts, setting
new default values in the .config and is used for the authoritative
values during the other scripts.
Yes, but I do not want to store the password *anywhere* - it could even
be removed from debconf database because it makes no sense to store it
in case the local maintainer changes the database password the value
is absolutely useless in any config file or debconf database. Moreover
it is even a security risk to store a password in an additional place.
So my question remains: How to obtain the admin-pass value for the
database application in question *inside* the postinst script.
Otionally we should remove it from debconf database in the end of the postinst
script.
the only problem i see with "any" is that in the future there may be
more non-sql database types handled this way. in the existing framework
there's a debconf variable package/dbtype which gets the dbtype
in question, which is i think what you'd use. now that i'm taking
a look at what's currently there, i see that i'm not actually writing
this variable to the config file. i think that was originally because
i didn't want it to be something configurable if the package didn't
support it.
the plan as it stands now is to have maintscripts for each dbtype,
and then to also have a central master maintscript, to which you can
feed environment variables such as the supported database types. this
central script would then take those and populate a the dbtype template
as a select question. something like
dbtypes="mysql postgresql"
. /usr/share/dbconfig-common/dpkg/config
Sure. My problem with your current 0.7 version is that yu provide *.mysql
scripts which are about 90% reusable for postgresql. IMHO we should do
something like
{config,postinst,postrm,preinst,prerm}
which source a further file containig special things for the database
in question according to the variable $DBTYPE like
. /$DBTYPE/`basename $0`
This avoids mainly doubling of code.
Well, I guess this might be solved by "su" as mentioned above, but
my problem is, who to access the values the user have input in the
debconf questions? I need to know some of these values in the
script.
a ". /etc/dbconfig-common/$package.config" should take care of that.
As I said - I do not want to write passwords into extra files. But if this
file would be created by the config script I could read this file in postinst
and remove the password afterwards from there while keeping the other
values untouched. I did not really tested the dbconfig-common stuff because
I was unsure about the postgresql issue but did I understand you right,
that this file exists after finishing the configure script?
Depends
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its Depends field
have been correctly configured.
and since the postinst script is where all the db-changing code occurs,
you don't have to worry about whether or not the locales is being run
before the main package, if i'm understanding both you and policy :)
Well, the policy speaks only about *configuration*. But the main database
is installed in the *postinst* script. I did not found anything about the
fact that the postinst from a dependant package has to be installed first.
But the locale part of the database only installs if the main server exists
in the postgresql database.
also, fyi, i have initial postgresql support in the latest version of
the package (0.8, which i haven't uploaded yet, but will be in the next
day or two). the one thing lacking is proper dumping and recovering from
errors, as i haven't spent enough time looking at the pg_dump manpage.
I'd volunteer to check that.
ps: i'm not cc'ing d-d, but feel free to do so in your replies if you
like.
Done, because I think it is interesting also for others.
Kind regards
Andreas.
--
http://fam-tille.de
Re: removing in postrm rc*.d symlinks that I did not create
On Thursday 16 December 2004 00.34, Nicolas Boullis wrote: [de-installing run-level links that weren't installed] How about installing links as /etc/rc?.d/K??foo - so the links are there and are properly manageable, but the init script will only be called as 'K??foo stop' -- vbi -- Segunda ley ecológica: Nunca nada se va del todo. -- Commoner. pgpxgdJd9s49O.pgp Description: PGP signature
Re: installing a source tree?
Chasecreek Systemhouse <[EMAIL PROTECTED]> schrieb: > On Wed, 15 Dec 2004 18:35:40 +0100, Frank Küster <[EMAIL PROTECTED]> wrote: > >> What about apt-get source postgresql? > > Yes I did, but that doesn't place/install it into the proper places -- > what(where)ever they may be. I could have just as easily download the > source from postgressql website and installed it into /usr/local ... > thereby by-passing the Debian stuff. If you know where your software wants the postgresql sources, simple issue the apt-get source command from there - it always unpacks into the local directory. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: removing in postrm rc*.d symlinks that I did not create
On Thu, Dec 16, 2004 at 02:11:06AM +0100, Nicolas Boullis wrote: > Hi, > > On Wed, Dec 15, 2004 at 04:33:49PM -0800, Russ Allbery wrote: > > > > A technique that I've used in packages with this issue is to install the > > rc*.d symlinks by default, but also have the init script check a file in > > /etc/default to see whether or not to actually start at boot. If you > > install a default /etc/default file that says not to start, you accomplish > > the same thing, don't have this problem, and make it just as easy for > > users to enable the package. > > Thanks for your suggestion. > I already thought about it, but I fnind it quite confusing when I cannot > run /etc/init.d/foobar by hand as soon as it is not enabled on startup. Well, you could have a message saying that you need to enable foo and a 'force-start' action that started it regardless of what's in /etc/default. Moreover, the script could check if it's being called on startup (it's name is 'S') and heed the default value and start anyway if called from the command line. There are plenty of ways to avoid that confusion. Regards Javier signature.asc Description: Digital signature
Re: Help needed with debconf
On Wednesday 15 December 2004 17:04, Bartosz Fenski aka fEnIo wrote: > You didn't attached your rules file and I suppose that there is a > problem, which cause not displaying your question. > > Are you sure you've got dh_installdebconf in your binary-common > target in rules file? Otherwise your debconf stuff won't be included > automatically in your final package. Thanks. That actually solved it... #-) Cheers Arne -- Arne GÃtje (éçè) <[EMAIL PROTECTED]> (Spam catcher. Address might change in future!) PGP/GnuPG key: 1024D/685D1E8C Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpqpZ8fi20EP.pgp Description: PGP signature
Re: Help needed with debconf
On Wednesday 15 December 2004 16:32, Andreas Metzler wrote: > postinst: > #!/bin/sh > [...] > if [ "$variant" == "Unicode" ]; then > > That is a bashism which will fail if /bin/sh is dash. Use > [ "foo" = "bar" ] instead. Thanks... are there any more pitfalls like this? Scripts work now. Thanks. Cheers Arne -- Arne GÃtje (éçè) <[EMAIL PROTECTED]> (Spam catcher. Address might change in future!) PGP/GnuPG key: 1024D/685D1E8C Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. pgpmUKwcRX9A9.pgp Description: PGP signature
Re: Help needed with debconf
On Wednesday 15 December 2004 17:04, Bartosz Fenski aka fEnIo wrote: > You didn't attached your rules file and I suppose that there is a > problem, which cause not displaying your question. > > Are you sure you've got dh_installdebconf in your binary-common > target in rules file? Otherwise your debconf stuff won't be included > automatically in your final package. Thanks, that actually solved it... #-) Cheers Arne -- Arne GÃtje (éçè) <[EMAIL PROTECTED]> (Spam catcher. Address might change in future!) PGP/GnuPG key: 1024D/685D1E8C Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: If you really want Free firmware...
On Wed, Dec 15, 2004 at 07:59:34AM -0500, Chasecreek Systemhouse wrote: > On Wed, 15 Dec 2004 23:32:39 +1100, Hamish Moffatt <[EMAIL PROTECTED]> wrote: > > On Tue, Dec 14, 2004 at 10:01:59AM -0500, Chasecreek Systemhouse wrote: > > > > It would be nice if you included your name in your posts. > > Lordy. :-) It *is* in my posts. > > See below here ... > -- > WC -Sx- Jones "Dash Sx Dash" must be hard to pronounce quickly.. -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Bug#285518: misdn-utils includes a firmware loader
Manoj Srivastava <[EMAIL PROTECTED]> wrote: > On Tue, 14 Dec 2004 14:21:54 +0100, Simon Richter <[EMAIL PROTECTED]> said: > >> Hi, >>> It's fine for software in main to be able to do stuff with non-free >>> data; that's not the issue. The question is whether there *exists* >>> any free data that it works with, and if not, whether that's a >>> problem. > >> I don't believe that is a problem. We don't ship the non-free data, >> we just allow its use. I can see your point, however, that it is >> useless to ship an utility that cannot be used at present without >> having non-free data installed. > > Well, if you need the non-free component to be on the file > system, why is this different from contrib? When the issue of binary blobs in the kernel was first discussed here, if I'm not mistaken the proposed solution was to rewrite the respective drivers to be able to load the blob at runtime from "somewhere", and that somewhere would then be populated from non-free or an external source. And it was said that if the hardware device generally works without firmware loading, just with worse performance, or if most devices supported by the driver worked without, and just a minority depended upon it, then the driver (the kernel module or monolitic kernel) would be Free. Is this right? If yes, I don't see why this firmware loading software isn't free. Surely, for the kernel, the firmware loading code shouldn't be written dozens of times for dozens of drivers, but rather once in an external source file that is included by all those drivers to do the actual loading. And if the kernel can be freed by this procedure, this firmware loading code must be free. Why should analogous code, just in userland, be non-free? Or why isn't a firmware loading application analogous to kernel firmware loading code? Thanks in advance, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Help needed with debconf
"Arne Götje" <[EMAIL PROTECTED]> wrote: > On Wednesday 15 December 2004 16:32, Andreas Metzler wrote: >> postinst: >> #!/bin/sh >> [...] >> if [ "$variant" == "Unicode" ]; then >> That is a bashism which will fail if /bin/sh is dash. Use >> [ "foo" = "bar" ] instead. > Thanks... are there any more pitfalls like this? [...] Yes, there are, lintian finds most of them iirc and using dash as as /bin/sh in the sid chroot helps to find them, too. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" http://downhill.aus.cc/
Re: If you really want Free firmware...
On Thu, 16 Dec 2004 19:55:02 +1100, Hamish Moffatt <[EMAIL PROTECTED]> wrote: > > WC -Sx- Jones > > "Dash Sx Dash" must be hard to pronounce quickly.. LOL :-) Sx is an Action Verb. And it's damn easy to find in search engines; however my first mumblings into Usenet are likely deleted now -- I was on a CTOS (Convergent Technologies) kick in the early 90's. CTOS was a great, very well designed OpSys -- and look what happened to it. -- WC -Sx- Jones http://insecurity.org/
Re: Bug#285768: dselect survey
Hi, - If I see a new package installed by someone else, * if nothing depends on it, mark it "Unknown; probably manually installed" * otherwise, mark it "Unknown; probably automatically installed" Consider apt-get install foo apt-get remove foo This leaves libfoo1, which was pulled in by foo and is not depended on by anything, hence aptitude will consider it "probably manually installed". Most cases where this feature is needed (i.e. unless migrating from another PM) are like this one, where you really want the package removed. Packages in Unknown state that are depended on by other packages could be shown in the preview in a separate section, so you can go on the section line, tap M and then manually go through the list and mark everything that is actually needed. "Unknown; probably manually installed": I don't see doing anything especially fancy here, but there should be a way to show all of them on demand. Show all of them in the preview. "Unknown; probably automatically installed": If one of these packages is only [transitively] depended upon by some other packages in the same class, tell the user that they all are possibly unused. (for instance, in the preview screen) Such a state would be used only seldom, it applies only to packages installed automatically with another PM where the depending package is removed with aptitude. One problem is that the set of packages that are possibly unused isn't disjoint to the other sets of packages that aptitude displays, which could perhaps lead to some awkward situations. (what if a package is both upgradable and possibly unused? Which category is it listed in, or is it listed in both?) Two categories, like the distinction between automatically installed new packages and new packages. In total, we get four new categories. Simon signature.asc Description: OpenPGP digital signature
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 08:27:20 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> wrote: > On Wed, 15 Dec 2004, sean finney wrote: > Yes, but I do not want to store the password *anywhere* - it could even > be removed from debconf database because it makes no sense to store it > in case the local maintainer changes the database password the value > is absolutely useless in any config file or debconf database. Moreover > it is even a security risk to store a password in an additional place. If it's only readable by root, how much of a risk is it really?
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, Olaf van der Spek wrote: Yes, but I do not want to store the password *anywhere* - it could even be removed from debconf database because it makes no sense to store it in case the local maintainer changes the database password the value is absolutely useless in any config file or debconf database. Moreover it is even a security risk to store a password in an additional place. If it's only readable by root, how much of a risk is it really? Why should I use md5 passwords if they are stored in /etc/shadow which is only readable by root? IMHO, it is a good idea not to store passwords in clear text if there is no reason to do so. If a temporary file at install time suffices I just prefer this over permanent storage. Kind regards Andreas. -- http://fam-tille.de
Re: LCC and blobs
hoi :) On Sat, Dec 11, 2004 at 05:49:26PM -0500, Glenn Maynard wrote: > If the driver has to be able to open the file and read the blob so it > can send it to the device, there's a clear relationship and dependency > between the driver and the blob: if you don't have a copy of the blob, > the driver doesn't work. (Spewing out "hardware error, firmware not > loaded" doesn't count to me as "working".) I have a PCMCIA card that lost its flash memory. So suddenly its driver became non-free? What about all those drivers for hardware that I don't own? They don't work for me, yet I won't flag them as non-free. We must not consider hardware when talking about free software. Sending firmware to the device is not that different to sending some magic initialization commands. Firmware should be treated as exactly that: magic initialization data for the device. -- Martin Waitz signature.asc Description: Digital signature
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 14:22:25 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> wrote: > On Thu, 16 Dec 2004, Olaf van der Spek wrote: > > >> Yes, but I do not want to store the password *anywhere* - it could even > >> be removed from debconf database because it makes no sense to store it > >> in case the local maintainer changes the database password the value > >> is absolutely useless in any config file or debconf database. Moreover > >> it is even a security risk to store a password in an additional place. > > > > If it's only readable by root, how much of a risk is it really? > Why should I use md5 passwords if they are stored in /etc/shadow which > is only readable by root? Because system passwords aren't 'needed' by any applications to authenticate themselves to the system, while database passwords are. > IMHO, it is a good idea not to store passwords in clear text if there > is no reason to do so. If a temporary file at install time suffices > I just prefer this over permanent storage. True, but how many database apps work without storing the password?
Re: LCC and blobs
hoi :)
On Sun, Dec 12, 2004 at 12:57:09AM +0100, Goswin von Brederlow wrote:
> >> Would you accept a patch for ppp of the form:
> >>
> >> char data[] = { 0x17, 0x23, 0x42, ...};
> >> ...
> >> *(int (*)(int))data(fd);
> >>
> >> After all, it is just data.
> > No, because these bytes are executed on the system CPU under the control
> > of the OS, so to me they look like software.
>
> Where in the GPL does it say anything about being executed or where or
> under which control? Where does the DFSG say something about that?
with such a reasoning, /ALL/ drivers are non-free because they send
commands to the hardware and it gets executed by the hardware.
Every driver has to initialize its device by sending some magic
commands. It's none of our business what the device is doing with
these commands. If it stores the bytes in RAM, that's fine.
Firmware is just a long initialization command.
--
Martin Waitz
signature.asc
Description: Digital signature
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, Olaf van der Spek wrote: Because system passwords aren't 'needed' by any applications to authenticate themselves to the system, while database passwords are. No, they are not needed in the file system. They are needed inside the database and they are save there (assumed that the database server has no bugs). True, but how many database apps work without storing the password? At least these that do authentification directly against the database should not store their passwords in an extra file. This is the case for the application I'm currently working on (GnuMed) where the client does the authentication via user interaction. Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 14:55:29 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> wrote: > On Thu, 16 Dec 2004, Olaf van der Spek wrote: > > > Because system passwords aren't 'needed' by any applications to > > authenticate themselves to the system, while database passwords are. > No, they are not needed in the file system. They are needed inside > the database and they are save there (assumed that the database server safe? Yes, but that's the other side of the authentication end. This is about the client, not the server. > has no bugs). > > > True, but how many database apps work without storing the password? > At least these that do authentification directly against the database > should not store their passwords in an extra file. This is the case > for the application I'm currently working on (GnuMed) where the > client does the authentication via user interaction. Is that the majority or the minority of applications? Take for example a web application like a forum. It requires the password so it can connect to the database. It can't/won't ask the password from the user.
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, Olaf van der Spek wrote: Is that the majority or the minority of applications? Take for example a web application like a forum. It requires the password so it can connect to the database. It can't/won't ask the password from the user. Can you tell me any reason why I should store a clear text password in a text file for *my* application only because *other* applications would require this? Kind regards Andreas. -- http://fam-tille.de
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 15:34:35 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> wrote: > On Thu, 16 Dec 2004, Olaf van der Spek wrote: > > > Is that the majority or the minority of applications? > > Take for example a web application like a forum. It requires the > > password so it can connect to the database. It can't/won't ask the > > password from the user. > Can you tell me any reason why I should store a clear text password > in a text file for *my* application only because *other* applications > would require this? Nope. But for apps that do require that, it makes sense to do it so you can avoid asking the password multiple times in the case of upgrades or other things.
Re: LCC and blobs
Martin Waitz <[EMAIL PROTECTED]> writes:
> hoi :)
>
> On Sun, Dec 12, 2004 at 12:57:09AM +0100, Goswin von Brederlow wrote:
>> >> Would you accept a patch for ppp of the form:
>> >>
>> >> char data[] = { 0x17, 0x23, 0x42, ...};
>> >> ...
>> >> *(int (*)(int))data(fd);
>> >>
>> >> After all, it is just data.
>> > No, because these bytes are executed on the system CPU under the control
>> > of the OS, so to me they look like software.
>>
>> Where in the GPL does it say anything about being executed or where or
>> under which control? Where does the DFSG say something about that?
>
> with such a reasoning, /ALL/ drivers are non-free because they send
> commands to the hardware and it gets executed by the hardware.
Not at all. Normal drivers communicate with the hardware over a define
protocol. Your reasoning is like saying wget is non-free because the
webserver it talks to is non-free.
> Every driver has to initialize its device by sending some magic
> commands. It's none of our business what the device is doing with
> these commands. If it stores the bytes in RAM, that's fine.
> Firmware is just a long initialization command.
That doesn't change the fact that the firmware is a program and as
such must follow the GPL (if released under GPL). For what it is used
or where it is executed is completly irelevant. All that matters is
that for Debian to distribute it the license has to be followed.
Even worse, with the SC change, the firmware has to be 100% free. Even
if you say it is just data it still has to be free. Whatever that
might entail.
> --
> Martin Waitz
MfG
Goswin
Re: RFC: common database policy/infrastracture
On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote: > Take for example a web application like a forum. It requires the > password so it can connect to the database. It can't/won't ask the > password from the user. But there is (or at least, should be) a specific user for that forum application, with the minimum of rights needed for that application (e.g. SELECT and UPDATE) in a single specific database. You're talking about a DB *admin* password. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004 08:51:32 -0600, Steve Greenland <[EMAIL PROTECTED]> wrote: > On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote: > > Take for example a web application like a forum. It requires the > > password so it can connect to the database. It can't/won't ask the > > password from the user. > > But there is (or at least, should be) a specific user for that forum > application, with the minimum of rights needed for that application > (e.g. SELECT and UPDATE) in a single specific database. You're talking > about a DB *admin* password. Ah, k. It makes less/no sense to store that password. But I wonder, is there no way to use the 'power' of the root account to do such DB administration without password then?
Bug#285942: ITP: mozilla-thunderbird-locale-pt-br -- Mozilla Thunderbird Brazilian Portuguese Language/Region Package
Package: wnpp Severity: wishlist * Package name: mozilla-thunderbird-locale-pt-br Version : 1.0 Upstream Author : Name <[EMAIL PROTECTED]> * URL : ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/ * License : MPL, GPL, LGPL Description : Mozilla Thunderbird Brazilian Portuguese Language/Region Package Brazilian Portuguese menu/message resource and region property package for Mozilla Thunderbird. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-1-386 Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Re: RFC: common database policy/infrastracture
On Thu, Dec 16, 2004 at 08:27:20AM +0100, Andreas Tille wrote:
> Yes, but I do not want to store the password *anywhere* - it could even
> be removed from debconf database because it makes no sense to store it
> in case the local maintainer changes the database password the value
> is absolutely useless in any config file or debconf database. Moreover
> it is even a security risk to store a password in an additional place.
well, the admin pass shouldn't be stored anywhere, or at least the
admin should be prompted whether or not the admin pass should
be stored. this is not the current behavior of dbconfig-common,
but it is the planned behavior.
> So my question remains: How to obtain the admin-pass value for the
> database application in question *inside* the postinst script.
> Otionally we should remove it from debconf database in the end of the
> postinst
> script.
ah. the short answer for the time being is that there's a variable
dbadmpass, which will have the answer stored. if your application
wants to get the admin password too, i don't see any problem with doing
a db_input/db_get again on the admin password question (it is a question
belonging to your package, after all), though if the password isn't
stored the admin could be prompted twice.
but something to point out: dbconfig-common already performs the
administrative actions needed to set up the database and database user
in the first place, so does your package even need the admin password?
> Sure. My problem with your current 0.7 version is that yu provide *.mysql
> scripts which are about 90% reusable for postgresql. IMHO we should do
> something like
>
> {config,postinst,postrm,preinst,prerm}
>
> which source a further file containig special things for the database
> in question according to the variable $DBTYPE like
>
> . /$DBTYPE/`basename $0`
take a look at 0.8 :) this was the plan all along, but i had to start
with what i knew. also, i discovered that you can't reliably use
$0 in the maintainer scripts because when a package is first
preconfigured before being unpacked the filename doesn't follow
the same naming scheme. but now there are subscripts for
the supported mysql and pgsql database types, and a larger common
type (which will eventually support applications that support
multiple db types):
mini-me[~]10:28:00$ ls /usr/share/dbconfig-common/dpkg/
commonpostinstpostrm.mysql preinst.pgsql
configpostinst.mysql postrm.pgsql prerm
config.mysql postinst.pgsql preinstprerm.mysql
config.pgsql postrm preinst.mysql prerm.pgsql
> >a ". /etc/dbconfig-common/$package.config" should take care of that.
> As I said - I do not want to write passwords into extra files. But if this
> file would be created by the config script I could read this file in
> postinst
> and remove the password afterwards from there while keeping the other
> values untouched. I did not really tested the dbconfig-common stuff because
> I was unsure about the postgresql issue but did I understand you right,
> that this file exists after finishing the configure script?
for the admin pass, it should be configurable globally whether or not
the admin password is stored at all. for the user password, it will
have to be stored in a file somewhere anyway for whatever application
uses the database, so i'm not too concerned about that.
i'm not against providing a way around that, however, if there really
is a situation in which you wouldn't need the password.
> Well, the policy speaks only about *configuration*. But the main database
> is installed in the *postinst* script. I did not found anything about the
> fact that the postinst from a dependant package has to be installed first.
> But the locale part of the database only installs if the main server exists
> in the postgresql database.
i believe that when policy speaks of configuration it is in fact
speaking of the postinst script. the .config script is usually
referred to as "pre-configuration". with pre-configuration, it is
true that you can't rely on any dependencies being met, but touching
files in the .config script is generally a bad practice, and i don't do
anything other than ask debconf questions in the config script.
sean
--
signature.asc
Description: Digital signature
Re: RFC: common database policy/infrastracture
On Thu, Dec 16, 2004 at 04:17:11PM +0100, Olaf van der Spek wrote: > Ah, k. It makes less/no sense to store that password. > But I wonder, is there no way to use the 'power' of the root account > to do such DB administration without password then? in mysql, at least, there is. however, you have to take the database down in order to do it, which isn't really acceptible imho. sean -- signature.asc Description: Digital signature
Bug#285950: ITP: java-snmp -- Open Source implementation of the SNMP protocol in Java
Package: wnpp Severity: wishlist * Package name: java-snmp Version : 1.3 Upstream Author : Jon Sevy <[EMAIL PROTECTED]> * URL : http://edge.mcs.drexel.edu/GICL/people/sevy/snmp/snmp.html * License : BSD Description : Open Source implementation of the SNMP protocol in Java The Java SNMP package is an open-source implementation of the SNMP protocol as a Java package. It provides support for basic SNMP client and agent operations as defined in SNMP versions 1 and 2 (excluding the security model proposed as part of SNMP version 2, which was never widely accept or deployed). The package provides a mechanism for "getting and setting" SNMP object identifier (OID) values through a simple communication interface, and represents SNMP structures and datatypes as corresponding Java objects.
Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, sean finney wrote: but something to point out: dbconfig-common already performs the administrative actions needed to set up the database and database user in the first place, so does your package even need the admin password? The applilcation I want to package comes with a quite complex bootstrap script which does *all* setup (including creating the database and adding an admin account). So what we could do here: 1. From a Debian point of view provide an option for debconf which just tells postinst not to create the database etc, because the bootstrap script would take over this job. Just provide the data which are needed in a defined interface instead. 2. From the application point of view I could ask people to include an option which prevents the bootstrap script from doing the work which is just done. I guess this is no big deal for the very responsive authors. take a look at 0.8 :) URL? I hope you would announce new versions or just move the package to experimental to keep people informed. this was the plan all along, but i had to start with what i knew. also, i discovered that you can't reliably use $0 in the maintainer scripts because when a package is first preconfigured before being unpacked the filename doesn't follow the same naming scheme. Sure. The use of $0 was just to make things clear as a sketch. The implementation has to be a bit more precise... but now there are subscripts for the supported mysql and pgsql database types, and a larger common type (which will eventually support applications that support multiple db types): mini-me[~]10:28:00$ ls /usr/share/dbconfig-common/dpkg/ commonpostinstpostrm.mysql preinst.pgsql configpostinst.mysql postrm.pgsql prerm config.mysql postinst.pgsql preinstprerm.mysql config.pgsql postrm preinst.mysql prerm.pgsql While this is only cosmetics I would prefer storing the database specific stuff in separate directories. If we will have more databases it would be more easy to read. for the admin pass, it should be configurable globally whether or not the admin password is stored at all. This would be nice. for the user password, it will have to be stored in a file somewhere anyway for whatever application uses the database, so i'm not too concerned about that. No problem with that. If the package maintainer thinks it has to be deleted afterwards - there will be a way to do so ... i'm not against providing a way around that, however, if there really is a situation in which you wouldn't need the password. If all else fails: dd if=/dev/zero of=/dev/hda ;-) i believe that when policy speaks of configuration it is in fact speaking of the postinst script. the .config script is usually referred to as "pre-configuration". with pre-configuration, it is true that you can't rely on any dependencies being met, but touching files in the .config script is generally a bad practice, and i don't do anything other than ask debconf questions in the config script. Well, if this is really the case than it would save a certain amount of time for me. While I think this is a perfectly reasonable requirement I remember times were this was not the case and I had trouble to work around this. Kind regards Andreas. -- http://fam-tille.de
Re: On the freeness of a BLOB-containing driver
Goswin von Brederlow wrote: [EMAIL PROTECTED] (Nathanael Nerode) writes: Goswin von Brederlow wrote: ^^ This is wrong. Glenn Maynard? If it comes down to "the driver, on its own, would not be acceptable for main because it is not functional; but as a practical matter, we allow it aggregated with the rest of the kernel because splitting individual drivers into contrib is a pain for everyone involved and not worth the theoretical benefits", I can live with that. Yes, yes! Let me say that this is precisely what I think. "contrib" exists for software which is free but fails SC#1, "we will never make the system depend on an item of non-free software". Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. Suppose the thing being moved is not a vital part of the system. Then, although the item being moved depends on non-free software, does the *system* really depend on it? Then it pretty much comes down to what you said above. :-) -- This space intentionally left blank. You misquoted. That wasn't me. Oops, very sorry. Glenn Maynard? Hand-quoting sucks, but I've been reduced to it recently.
Are mails sent to xxxx@buildd.debian.org sent to /dev/null ?
One month ago, I asked the alpha and mips buildd maintainers to reschedule h5utils, which failed to build because of a missing build for dependency. Was this email even read? Do these addresses have an utility in the real world? Do I have to re-upload a new version with no change, just to make it propagate to sarge? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: RFC: common database policy/infrastracture
In article <[EMAIL PROTECTED]>, Olaf van der Spek <[EMAIL PROTECTED]> wrote: >On Thu, 16 Dec 2004 08:51:32 -0600, Steve Greenland ><[EMAIL PROTECTED]> wrote: >> On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote: >> > Take for example a web application like a forum. It requires the >> > password so it can connect to the database. It can't/won't ask the >> > password from the user. >> >> But there is (or at least, should be) a specific user for that forum >> application, with the minimum of rights needed for that application >> (e.g. SELECT and UPDATE) in a single specific database. You're talking >> about a DB *admin* password. > >Ah, k. It makes less/no sense to store that password. >But I wonder, is there no way to use the 'power' of the root account >to do such DB administration without password then? With postgres - sure. You can use 'ident' authentication. It looks up who is at the other end of the socket/connection using ident for TCP or local credentials for Unix sockets. Based on that you can allow all sorts of access (using pg_hba.conf and pg_ident.conf) Mike.
Re: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?
Josselin Mouette debian.org> writes: > One month ago, I asked the alpha and mips buildd maintainers to > reschedule h5utils, which failed to build because of a missing build for > dependency. Was this email even read? Do these addresses have an utility > in the real world? The source package fseries was over 40 days behind on s390 and arm when I mailed the respective [EMAIL PROTECTED] A few days later, an s390 package was built, whether or that was due to my mail I do not know. For arm, I am still waiting: Checking fseries * trying to update fseries from 191.10057-1 to 200.10058-1 \ (candidate is 63 ays old) * fseries is not yet built on arm: 191.10057-2 vs 200.10058-1 > Do I have to re-upload a new version with no change, just to make it > propagate to sarge? Good question. Any takers? Dirk
Re: Linux Core Consortium
On Tue, 2004-12-14 at 23:22 +0100, Christoph Hellwig wrote: > On Tue, Dec 14, 2004 at 08:34:17AM -0500, Ian Murdock wrote: > > On Fri, 2004-12-10 at 00:44 +0100, Christoph Hellwig wrote: > > > Besides that the LCC sounds like an extraordinarily bad idea, passing > > > around binaries only makes sense if you can't easily reproduce them from > > > the source (which I defined very broadly to include all build scripts > > > and depencies), and that case is the worst possible thing a distribution > > > can get into. > > > > The LCC core will be fully reproducible from source. You may > > (and probably will) lose any certifications if you do that, > > for the same reason that the distros reproduced from the Red > > Hat Enterprise Linux source (e.g., White Box Linux) lose them. > > But it won't be take it or leave it. If reproducing from > > source and/or modifying the core packages is more important to > > you than the certifications, you will be able to do that. > > So again what do you gain by distributing binaries if their reproducible > from source? So, again, ISV and IHV certifications. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ "All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible." -T.E. Lawrence
Re: Linux Core Consortium
On Tue, 2004-12-14 at 18:15 +0100, Tollef Fog Heen wrote: > This sounds a bit like the government whose country had three > different types of power plugs. None compatible, of course. Somebody > then got the great idea that if they invented another one to supersede > the three plugs in use (since that caused overhead). That country now > has four plugs in use. Actually, it's more like the country that has a few dozen different types of power plugs, and they're all so minutely different from each other that the consumer has no idea why it's like that, only that if he buys something that requires electricity, he can only use what he buys in 50% of the places that have electrical power. Also, the differences are small enough that he *might* be able to plug in what he has bought in some of the other places, but he's never sure if or when the thing he plugs in will blow up. Three of the six makers of the most common plug types then get together, realize the stupidity of the current situation, and decide to correct it. At the very worst, there are two fewer plug types. At the very best, the dozens of others gradually disappear too. The end result is that consumers can now buy electrical equipment that work in more places. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ "All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible." -T.E. Lawrence
Re: Linux Core Consortium
On Wed, 2004-12-15 at 23:55 +0100, Bill Allombert wrote: > On Wed, Dec 15, 2004 at 02:36:52PM -0800, Bruce Perens wrote: > > Bill Allombert wrote: > > > But overriding them means we lose the certification ? > > > > We can't allow it to be the case that overriding due to an existing and > > unremedied security issue causes loss of certification. There's no > > common sense in that. > > Then could you elaborate the scope of the certification ? It is one > of the main contender for me. I though the certification require to > ship the exact same binary as provided by the LCC. The LCC will be pursuing its certification efforts through the existing LSB certification process. The smaller ISVs will be more willing to be flexible, so changes to the core that don't result in loss of LSB compliance may be acceptable to them. We've heard directly from the biggest ISVs that nothing short of a common binary core will be viable from their point of view. So, as with all things in this business, there will be tradeoffs involved--you'll be free to make changes, at the potential loss of some, though not necessarily all, ISV certifications. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ "All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams with open eyes, to make it possible." -T.E. Lawrence
Re: Linux Core Consortium
On Wed, 2004-12-15 at 07:42 -0800, Steve Langasek wrote: > > "Core" means "implemention of LSB", and the packages/libraries that will > > constitute that are being determined now, as a collaborative process. > > Well, for instance, the libacl package was brought up as an example in the > context of changing library SONAMEs/package names. The current LSB has > nothing to say about this library; it covers only glibc, libstdc++, various > core X libraries, zlib, libpam, libgcc, and ncurses. So there was some doubt > in my mind as to how broad a "core" ISVs were actually demanding be > specified, as well as doubt regarding the conclusion that the LSB process > was flawed if the simple fact was that ISVs were demanding standardization > of libraries that no one has asked the LSB to address. Doing an apt-cache showpkg on libacl1, I see coreutils depends on it. I don't see coreutils in the list of dependencies of the "lsb" package, so I assume it's implicitly pulled in by one of the other dependencies, since LSB 2.0 does require ls and some of the other commands provided by coreutils. So, by following the dependencies, libacl1 would be in that core too even if the LSB has nothing to say about it. > I still think "implementation of the LSB" is a murky concept; the LSB > specifies very little about kernel behavior after all (though some things > are implicit given the description of libc ABIs plus the de facto glibc > implementation of them), so I don't know whether and how many userspace > tools it's also seen as essential to cover. Yes, it's murky, but as you point out, and as the libacl1 example shows, there's still considerable room for interpretation while remaining LSB-compliant. We're trying to make the LSB stronger and more tangible by building a reference implementation that software developers and ISVs can target, knowing that what they're targeting is in use in the real world and not just a "sample implementation" that may differ dramatically from the LSB-certified distros their customers are using. > > I assumed Debian would want to be involved in this process too, rather > > than being presented with a more well-defined scope as a fait accompli.. > > Particularly considering involvement in the LCC would require essentially > unanimous consent of the maintainers of the covered core packages, I think > it's impossible for Debian to be meaningfully involved without first having > a clear understanding of what would be expected of us -- especially when > late bouts of scope creep could hamstring the entire effort by suddenly > requiring the consent of a new package maintainer who doesn't approve! I > think it's better if this can all be laid out up front so we can get a clear > yea or nay from the affected maintainers before sending people off to > committee. I agree, and I probably pushed too strongly on my "ideal scenario", which no doubt led to the "all or nothing" perception that seems to be prevailing in this thread. The right thing to do now is for interested parties within the project to begin discussing what Debian would want in the core, development processes, etc., and to engage the LCC as a separate group and/or as individuals to make sure Debian has a voice. Whether Debian uses or is at least influenced by the result of the LCC's work down the road should be a separate question, though it's a strongly related question, because if "what would be expected of us" turns out to be unrealistic or unachievable, the former will be a non-starter. That's why Debian's voice needs to be heard now. > > As I said at the very outset, one possible way forward is to simply > > produce a Debian-packaged version of the LCC core independently, > > and to make sure that core is 100% compatible with Debian (i.e., you > > can take any Debian package and install it on the LCC Debian core > > and get the same results as if you'd installed it on Debian itself). > > I would prefer to take this a step further in the opposite direction. Given > that the LSB specifies a determined linker path as part of its ABI other than > the one used by the toolchain by default, and given that the kernel is > largely an independent, drop-in replacement wrt the rest of the packaging > system, why *couldn't* we provide the LCC binaries in the same fashion as the > current lsb package -- as a compatibility layer on top of the existing > Debian system? This sidesteps the problem of losing certification over > small divergences that significantly impact our other ports and is a much > more tractable goal, while still giving us a target to aim for with our base > system. That's certainly a way forward too, and we will explore it. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ "All men dream: but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity: but the dreamers of the day are dangerous men, for they may act their dreams
Re: Linux Core Consortium
Op do, 16-12-2004 te 14:46 -0500, schreef Ian Murdock: > We've heard > directly from the biggest ISVs that nothing short of a common > binary core will be viable from their point of view. Well, frankly, I don't care what they think is 'viable'. 'ISV' is just another name for 'Software Hoarder'. I thought Debian was about Freedom, not about "how can we make the life of proprietary software developers easy?" As a distribution consisting only of Free Software, Debian has very good reasons to not distribute third-party binaries. That's what the LCC binaries will be: third-party. We should not compromise all that we have and all that we stand for, for the benefit of some Enterprise Managers and people advocating non-free software. If the LSB doesn't work, the non-free hoarders are free to suggest improvements where applicable; if it is impossible to create a single binary that will run on all LSB-certified distributions, then that is a bug in either the LSB process (by failing to provide a well enough defined standard), the non-free software (by relying too much on a single implementation of the standard), or the toolchain (by not being able to correctly manage the ABI of built libraries). That bug may be worked around by providing a common binary core; it will, however, not actually be fixed by doing so. One of the major benefits of Free Software is the ability to fix bugs without having to rely on external factors. If, however, rebuilding your C library will result in the loss of your support contract, you will essentially have lost that benefit, and many more with it. I refuse to accept that 'providing a common binary core' would be the only way to fix the issue. It is probably the easiest way, and for lazy people it may look as if it is the only one; but we should not dismiss the idea that it is possible to fix the Free software or the standard so that the LSB /will/ work. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Bug#285993: ITP: phpmyvisites -- Powerful application for websites statistics and audience measurements.
Package: wnpp Severity: wishlist * Package name: phpmyvisites Version : 1.2.2 Upstream Author : Matthieu AUBRY <[EMAIL PROTECTED]> * URL : http://www.phpmyvisites.net/ * License : GPL Description : Powerful application for websites statistics and audience measurements. phpMyVisites is an open-source and free application for the management of statistics of websites. After you have installed the application on your web server (the installation phase is completely automated and does not required any technical knowledge), you need to insert a short Javascript code (you will be able to copy and paste it) on the pages from where you wish to obtain statistics: the setup is very simple and immediate. Everyone will be able to take advantage of the statistics. It can be that you are only intested by the number of web page consultation, the average time that your visitors pass on your pages, or again if you wish to analyze in depth your statistics (in taking advantage of several features of phpMyVisites) and to have like this, means to progress on your website. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Bug#78782: Confirmation Link
Attention: One of our clients has requested to meet you. Client Profile #: 530-0215 Client Profile URL: http://date-clubz.com/tmember/2142313.php Have a Save and Happy Holiday Jessica Fischer Away From Home Inc. Customer Support
Re: Linux Core Consortium
Wouter Verhelst wrote: 'ISV' is just another name for 'Software Hoarder'. Please keep in mind this portion of Debian's Social Contract: We will support our users who develop and run non-free software on Debian One of the reasons for this is that you can get more people to appreciate Free Software if you can get it into their hands first. If they have no choice but to stick with RH and SuSE because they can't get their stuff supported elsewhere, they will never get our message. Thanks Bruce
Bug#285997: ITP: FUDforum -- Highly customizable forum package, with a large feature set.
Package: wnpp Severity: wishlist * Package name: FUDforum Version : 2.6.9 Upstream Author : Ilia Alshanetsky <[EMAIL PROTECTED]> * URL : http://fudforum.org/ * License : GPL Description : Highly customizable forum package, with a large feature set. FUDforum is a highly customizable forum package, with a large feature set. The easy to use administration control panel allows the administrator to easily configure and control the many features available. The forum also includes an interactive help package, which helps to familiarize users with the full potential of FUDforum. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Re: LCC and blobs
Martin Waitz <[EMAIL PROTECTED]> writes: > I have a PCMCIA card that lost its flash memory. > So suddenly its driver became non-free? No; the hardware is damaged. No driver can drive that. The driver you have is a driver for Foomatic Quxer cards. You don't have a Foomatix Quxer; you have a broken pile of junk. > What about all those drivers for hardware that I don't own? > They don't work for me, yet I won't flag them as non-free. > We must not consider hardware when talking about free software. > > Sending firmware to the device is not that different to sending some > magic initialization commands. Firmware should be treated as exactly > that: magic initialization data for the device. Exactly. And so we should require it to be free. Certainly, if some card required a long magic initialization sequence, but its licence prohibited distribution or modification of that sequence, we would not consider it free. The initialization sequence in these cases is long enough to be covered by copyrights. It's clearly software, and the driver clearly has a dependency on it. So either we should compromise our principles and ship the drivers without a reasonable expectation that anyone with the device will have the firmware, or else we should compromise utility and not ship with dependencies on non-free software. Since in the case of firmware on disk we can't reliably get the firmware to users *anyway*, utility's not atainable and we should keep our principles of freedom. -- Brian Sniffen [EMAIL PROTECTED]
Re: Linux Core Consortium
me> binutils and modutils both depend on it. Bruce> On flex? No. At least not in unstable. sorry, I meant to write Build-Depend. me> Or is the LCC proposing to standardize on a set of binaries without me> specifying the toolchain that's used to reproduce them? Bruce> Linking and calling conventions should be standardized and should Bruce> survive for reasonably long. We need to know what we use to build the Bruce> packages, but we are not currently proposing to standardize development Bruce> tools on the target system. Agreed there needn't be development tools on the target system. But the development system itself needs to be fully and accurately specified, both among the participating distros and to the end users. That's what it takes to satisfy the letter of the GPL, at least as I read it, and it's certainly the standard to which Debian packages are held. It's going beyond the level of effort that has historically been put into binary distributions, but I don't think it's too much to ask in this context. me> Not having a policy is also a choice. For a variety of reasons, a me> written policy about legal and technical issues can be a handicap to me> the sort of calculated risk that many business decisions boil down to. Bruce> "The sort of calculated risk that many business decisions boil down to" Bruce> is too vague to have meaning. What you may be groping at is that some Bruce> publicized policy can be taken as a promise. The organizations Bruce> participating in LCC have chosen to make such promises. I wasn't groping, I was trying to leave it to the reader's imagination rather than rehash old flamewars. On the legal side, for instance, some distros have been known to be cavalier about GPL+QPL and GPL+SSLeay license incompatibilities. On the technical side, expecting releases to be self-hosting can constrain release timing relative to toolchain changes. I tend to be skeptical of promises that I think are logically contradictory. Promising ISVs that they need only test against "golden" builds, while promising end users the Four Freedoms, doesn't add up. Note that if Distro X distributes both NonFreeWareApp and glibc, and only offers technical support on NonFreeWareApp to those who don't recompile their glibc, then Distro X's right to distribute glibc under the LGPL is automatically revoked. (IANAL, etc., etc., but I don't see much ambiguity in this.) Cheers, - Michael
Re: Linux Core Consortium
On Thu, Dec 16, 2004 at 09:25:38PM +0100, Wouter Verhelst wrote: > Op do, 16-12-2004 te 14:46 -0500, schreef Ian Murdock: > > We've heard > > directly from the biggest ISVs that nothing short of a common > > binary core will be viable from their point of view. > > Well, frankly, I don't care what they think is 'viable'. > > 'ISV' is just another name for 'Software Hoarder'. I thought Debian was > about Freedom, not about "how can we make the life of proprietary > software developers easy?" Regardless of how you feel about proprietary software, it is someone else's work and they are free to sell or license it as they see fit. I don't see how someone advocating "freedom" can in the same (virtual) breath presume to dictate what other people do with their work. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Packaging true type fonts with minor variation
Hi folks,
I have a question on how to package true type fonts while making tiny
section of fonts to be made debconf selectable.
(This is related to ttf-arphic-{ukai|uming} font packages.)
Current solution I suggested to the packager was to provide binary diff
and apply it everytime debconf are run. (Yes we need a set of diff
files to patch and unpatch.)
But this is not really elegant. If I know the true type font file
structure better, maybe there is better solution.
If this is done properly, we can have an unicode fonts with its font style
customizable per each section
Anyone?
Osamu
--
Example of minor font change: 0 with/without center dot
Re: Linux Core Consortium
On Thu, 16 Dec 2004 21:25:38 +0100, Wouter Verhelst <[EMAIL PROTECTED]> wrote: [snip] > Well, frankly, I don't care what [ISVs] think is 'viable'. I do care. Apparently some ISVs think a "common binary core" is viable. I think they might change their minds if the argument against "golden binaries" is made with reference to historical reality (golden binaries don't stay golden) as well as Free Software principle, and if their problem is taken seriously and respectfully enough to propose a better answer. It is not enlightenment to despise the unenlightened. Cheers, - Michael
GPL and LGPL issues for LCC, or lack thereof
Michael K. Edwards wrote: Agreed there needn't be development tools on the target system. But the development system itself needs to be fully and accurately specified, both among the participating distros and to the end users. That's what it takes to satisfy the letter of the GPL, at least as I read it The particular GPL text concerning the development system is: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. This does not require specification of the development environment. It does define that scripts used to control compilation and installation, such as shell scripts and makefiles related to that particular project/, would be considered source code. Note that if Distro X distributes both NonFreeWareApp and glibc, and only offers technical support on NonFreeWareApp to those who don't recompile their glibc, then Distro X's right to distribute glibc under the LGPL is automatically revoked. The word "support" does not appear in the LGPL. What I do see is: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. This would imply that support is outside the scope of the license. I don't see any language in the LGPL specifying a support obligation of any kind. Thanks Bruce
The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
I think we're looking at this from the wrong end. Using Free Software, it's easy to produce more Free Software in such a way that it will run on all Free platforms. This is normal; most, if not all, Free Software is built by people who mainly (or only) use Free Software, so they do not usually look at the specific needs that developers of non-free software have. At some point, developers of non-free software came along, and tried to produce non-free software for the Free platforms. These non-free developers had a background on non-free platforms, where "a platform" is a bunch of binaries that were compiled at a single "vendor". Since everyone running one of those platforms has the exact same compiled form, it is easy to produce a standard so that one can compile software that will run on /all/ versions of the same platform; after all, there is only "one" version (not considering later or earlier iterations of the same platform). This is not true if you're running a free software platform, where technically everyone can create his 'own' version. As a result, people who write non-free software are having issues. To address these issues, the Free Software people created the LSB: a standard that defines what a binary form of the source "out there" should look like. This way, non-free developers can theoretically write against that standard, and distribute a compiled binary that will run "everywhere". Obviously, that hasn't worked. The non-free developers are having issues with their software if they write against the standard, so that it does not, in fact, run everywhere. They look at the non-free platforms and say 'it works over there, so it should work here'. They look at the differences between the non-free platforms and the Free platforms, and see that the non-free platforms are bit-by-bit the same thing everywhere whereas the Free platforms are not. Thus, they conclude that to solve the issue, the Free platforms should be bit-by-bit the same thing everywhere, too. That is, indeed, one way to solve it: throwing out the Freedom we, Free Software developers, have, and slowly starting to move towards a non-free platform. But is that really what we want? I would think it is not. Instead of pointing us towards the non-free platforms with their binary-identicalness, I think the non-free software developers should tell us why the LSB has failed. They should tell us where the standard is not clear enough, or where the issues with the LSB are, so that they can be solved. This will require them to exhibit a level of cooperation that we are not used to see from non-free developers, but does that matter? After all, they want to get Free Software modified for their purposes. That is possible -- it is the very heart of Free Software that it can be modified for your own purposes -- but they should do it by using the rules of Free Software, not by trying to mold the Free Software in something which approximates the (to them more familiar) non-free software. Thus, the answer to the failure of the LSB is not "the Free Software people should be more helpful to the non-free people"; the correct answer is "the non-free people should be more helpful to the Free Software people". -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Bug#286007: ITP: alex-guestbook -- User-friendly, skinnable, PHP-based guestbook
Package: wnpp Severity: wishlist * Package name: alex-guestbook Version : 3.2 Upstream Author : Alexis Soulard <[EMAIL PROTECTED]> * URL : http://www.alexphpteam.com/ * License : GPL Description : User-friendly, skinnable, PHP-based guestbook User-friendly, skinnable, PHP-based guestbook -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Re: LCC and blobs
Brian Thomas Sniffen wrote: No; the hardware is damaged. No driver can drive that. The driver you have is a driver for Foomatic Quxer cards. You don't have a Foomatix Quxer; you have a broken pile of junk. So here you argue that because the firmware is gone the hardware is broken, correct? ... It's clearly software, and the driver clearly has a dependency on it. And now you consider it software just because the method of storage is different? How can the nature of the bytes change because they are stored on a disk? If the driver need to load the firmware or just needs to enable it is the same thing. Just think of the enable sequence as highly compressed firmware :-). So the driver has a dependency on the firmware, even if it is in the device itself. So we have to move all drivers that use devices with build-in firmware to contrib. That or we see that the firmware is actually part of the hardware and that uploading is just a natural thing a driver should do. The fact that most firmware cannot be redistributed or does not come as source just selects what we can ship or have to ask the user to provide. Since in the case of firmware on disk we can't reliably get the firmware to users *anyway*, utility's not atainable and we should keep our principles of freedom. I see no limitation of my freedom in using firmware. Please tell me how I am limited in my freedom. If I wanted a open source firmware I could buy a device with open firmware, Groetjes, Peter
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
On Thu, Dec 16, 2004 at 10:43:37PM +0100, Wouter Verhelst wrote: > Thus, the answer to the failure of the LSB is not "the Free Software > people should be more helpful to the non-free people"; the correct > answer is "the non-free people should be more helpful to the Free > Software people". Very well written, Wouter. Thanks. One other possibility -- and I don't know if it's true or not -- is that the organization working on LSB is itself the problem. -- John
Re: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?
> Josselin Mouette debian.org> writes: > > One month ago, I asked the alpha and mips buildd maintainers to > > reschedule h5utils, which failed to build because of a missing build for > > dependency. Was this email even read? Do these addresses have an utility > > in the real world? > > The source package fseries was over 40 days behind on s390 and arm > when I mailed the respective [EMAIL PROTECTED] A few days later, an s390 > package was built, whether or that was due to my mail I do not > know. I've sent messages to various [EMAIL PROTECTED] addresses many times for various reasons, and they have all always been ignored. The xerces23 and xerces24 packages are still on not-for-us lists for architectures that they do and always have worked on though I have requested resolution of this multiple times over many months, and the nip2 packages need to be requeued on some platforms because of failed build dependencies that have long since been resolved. My requests on this have also been ignored. > > Do I have to re-upload a new version with no change, just to make it > > propagate to sarge? > > Good question. Any takers? An alternative to this would be build manually on the missing architectures and to do a binary upload, right? Someone did this for me of the xerces packages. I can't do it myself because I'm not a DD yet (I was approved by my AM in August and by the front desk in September), so I'm not sure whether the sponsor used one of the available build systems or used his own system. (It was a powerpc build in this case that was needed, and he does have a powerpc.) I'm not sure if developers have any recourse when things get stuck in person wait, as seems to be the case with some autobuilder problems as well as with the NM process. My strategy has always been to be patient and to try to find an alternative. I'm sure the unwitting bottlenecks are overcommitted rather than uncaring, and I don't want to be a nag. Are there polite/helpful things those of us waiting on [EMAIL PROTECTED] can do to help speed the process? I've even resorted to sending email to the individual buildd admins, but this has also always failed, even though I try my best to be pleasant about it. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/
Intent to package ewiki
Package: ewiki ErfurtWiki is an implementation of the WikiWikiWeb hypertext system (written in the PHP scripting language). It allows everybody who comes along to edit and create new pages very easily. Copyright: ErfurtWiki is PublicDomain, which means that you can do with it whatever you want (that actually means it is free of copyright and any restrictions). So it is free as in beer, and you can fork it, rename it, commercialize it, or publish a derived version under the GNU GPL, BSD, MPL, CC* licenses or even Microsofts' EULA. Ewiki package can be found at: http://mentors.debian.net -- Tiago Bortoletto Vaz http://zadig.is.dreaming.org 0x6CC228A1 - http://pgp.mit.edu signature.asc Description: Esta =?ISO-8859-1?Q?=E9?= uma parte de mensagem assinada digitalmente
Filing bugs with upstream
Hi, So say I've found a bug in Nautilus that exists in upstream. Gnome has a well maintained bugzilla where I can file the bug. Do I then file a Debian bug pointing to the Gnome bugzilla report? I do I file a Debian bug and point the Gnome Bugzilla report to it. Or do I just file a Debian bug and hope the maintiner files one upstream? -i [EMAIL PROTECTED] http://www.gelato.unsw.edu.au signature.asc Description: Digital signature
Re: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?
On Thu, Dec 16, 2004 at 05:04:49PM -0500, Jay Berkenbilt wrote: > > Josselin Mouette debian.org> writes: > > > One month ago, I asked the alpha and mips buildd maintainers to > > > reschedule h5utils, which failed to build because of a missing build for > > > dependency. Was this email even read? Do these addresses have an utility > > > in the real world? > I've sent messages to various [EMAIL PROTECTED] addresses many > times for various reasons, and they have all always been ignored. Truely, do you expect faster reaction just because the mail addresses changed, but the receiving persons are still the same? Why should they react faster just because the mail was sent to an alias instead of the persons real mail address? > The > xerces23 and xerces24 packages are still on not-for-us lists for > architectures that they do and always have worked on though I have > requested resolution of this multiple times over many months, and the > nip2 packages need to be requeued on some platforms because of failed > build dependencies that have long since been resolved. My requests on > this have also been ignored. Are you surprised? I'm not. > > > Do I have to re-upload a new version with no change, just to make it > > > propagate to sarge? > > Good question. Any takers? > An alternative to this would be build manually on the missing > architectures and to do a binary upload, right? Someone did this for > me of the xerces packages. I can't do it myself because I'm not a DD > yet (I was approved by my AM in August and by the front desk in > September), so I'm not sure whether the sponsor used one of the > available build systems or used his own system. (It was a powerpc > build in this case that was needed, and he does have a powerpc.) Searching for someone with an appropriate arch is just a work around, no solution to the problem. Although the problem is well known and the solution is obvious, nobody seems to have the guts to make a change (or even to speak about it). > I'm not sure if developers have any recourse when things get stuck in > person wait, as seems to be the case with some autobuilder problems as > well as with the NM process. My strategy has always been to be > patient and to try to find an alternative. Sadly there's no alternative sometimes. :( > I'm sure the unwitting > bottlenecks are overcommitted rather than uncaring, and I don't want > to be a nag. Are there polite/helpful things those of us waiting on > [EMAIL PROTECTED] can do to help speed the process? I've even > resorted to sending email to the individual buildd admins, but this > has also always failed, even though I try my best to be pleasant about > it. It's not your fault, for sure. -- Ciao... // Ingo \X/
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
Wouter Verhelst wrote: To address these issues, the Free Software people created the LSB When I founded the LSB, the job I proposed for it was to do what the LCC is now proposing to do. I didn't believe that a paper standard alone would be effective at resolving cross-distribution compatibility issues, and it has proven not to be. A paper standard is certainly a helpful thing to have around, though, because it helps focus policy discussion and record the result. That is, indeed, one way to solve it: throwing out the Freedom we, Free Software developers, have, and slowly starting to move towards a non-free platform. This is sophistry. LCC would be constructed of Free Software and would itself be no less free than Debian main. They should tell us where the standard is not clear enough, or where the issues with the LSB are, so that they can be solved. Here I can turn your own argument upon itself. Why do we create paper standards? One important reason is that in the world of proprietary software, vendors would not share their source code, so they had to define what the program would do in human language instead. A paper standard is a second-hand description of something that our community has the unique ability to share, bypassing the paper. The essential technical problem with the LSB is that it is not sufficiently descriptive of every thing that a modern application must depend on, and is not within 10 years of being sufficiently descriptive at the rate that its development has been going. In addition, it is not the best possible technical solution to getting a bunch of Free Software-based distributions to be more compatibile with each other. Thanks Bruce
Re: Filing bugs with upstream
On Fri, Dec 17, 2004 at 09:26:44AM +1100, Ian Wienand wrote: > So say I've found a bug in Nautilus that exists in upstream. Gnome > has a well maintained bugzilla where I can file the bug. Do I then > file a Debian bug pointing to the Gnome bugzilla report? I do I file > a Debian bug and point the Gnome Bugzilla report to it. Or do I just > file a Debian bug and hope the maintiner files one upstream? I'd say, file a bug upstream, then file a bug in Debian with the upstream bug number and tagged +upstream, and then comment on the upstream bug with the Debian bug number. It largely depends on the relative responsiveness of upstream and the Debian maintainer, which can only be learnt by trying this and seeing what happens next. -- --- Paul "TBBle" Hampson, MCSE 7th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues
Op do, 16-12-2004 te 14:38 -0800, schreef Bruce Perens: > Wouter Verhelst wrote: > > To address these issues, the Free Software people created the LSB > When I founded the LSB, the job I proposed for it was to do what the > LCC is now proposing to do. I didn't believe that a paper standard > alone would be effective at resolving cross-distribution compatibility > issues, and it has proven not to be. A paper standard is certainly a > helpful thing to have around, though, because it helps focus policy > discussion and record the result. > > That is, indeed, one way to solve it: throwing out the Freedom we, Free > > Software developers, have, and slowly starting to move towards a > > non-free platform. > > > This is sophistry. LCC would be constructed of Free Software and would > itself be no less free than Debian main. Would it? I don't know what the essense of Free Software is to you; I suppose it is something different to each and everyone of us. However, to me, the essense of Free Software is that it allows one to modify the software as one sees fit. Remove that ability, and I don't see the software as Free anymore. By requiring software to be bit-by-bit identical to a given binary compilation, we would (at least partially) lose the ability to modify the software as we see fit, and thus, the software wouldn't be as Free anymore. This would be just a minor problem to us Distributors (who get to have a say in the LCC); however, it would be a significant problem to people interested in using now LSB, then LCC-certified software on platforms with extra patches (say, they recompile the kernel to include a specific feature that wasn't in the official LCC-certified kernel); they are at risk of losing any and all support they get from the non-free developer because of doing so. This must not happen. > > They should tell us where the standard is not clear enough, or where the > > issues with the LSB are, so that they can be solved. > Here I can turn your own argument upon itself. Why do we create paper > standards? One important reason is that in the world of proprietary > software, vendors would not share their source code, so they had to > define what the program would do in human language instead. > A paper standard is a second-hand description of something that our > community has the unique ability to share, bypassing the paper. That is simply not true. Our community has the ability to share source; that does not mean we should start sharing binaries, too. > The essential technical problem with the LSB is that it is not > sufficiently descriptive of every thing that a modern application must > depend on, I acknowledged that. My point is that one can, indeed, solve this by providing common binaries, but that doing so is the most ugly way to attack the issue. If the paper standard is insufficient, it should be improved. If there are issues with the toolchain that reduce the portability of the produced binaries, then the toolchain should be improved. If the non-free software wants to do things that are by its very nature not portable, well, then it should not do that. I do, however, not accept that the only way to improve the portability of non-free software would be to make Free Software less Free. > and is not within 10 years of being sufficiently descriptive at the > rate that its development has been going. In addition, it is not the > best possible technical solution to getting a bunch of Free > Software-based distributions to be more compatibile with each other. Then we will need to improve the compatibility in more ways than by just providing a paper standard. There are many technically elegant ways to do that. Using the same binary on all distributions is /not/ one of them. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?
On Thu, Dec 16, 2004 at 11:34:55PM +0100, Ingo Juergensmann wrote: > Although the problem is well known and the solution is obvious, nobody seems > to have the guts to make a change (or even to speak about it). Let's have a discussion about reducing our number of architectures. Attempting to support several thousand binary packages on a dozen architectures across three release flavours imposes a large cost (see e.g. Joey Hess' recent blogging about the increased sysadmin work he has to do so that he can test d-installer). So we know the costs. Can we quantify the benefits? In http://blog.bofh.it/id_66, Marco showed these numbers of downloads at the Italian site: architecture files downloaded i386 1285422 all 504789 powerpc 17754 ia64 10111 sparc3336 arm 850 alpha507 hppa 204 mipsel 91 m68k 15 mips 7 s390 4 total1823090 AFAIK this data has not been refuted. Clearly, for informed decision we'd need more data, from more hosts and over longer periods. But it would be nice if we based this discussion on /measurable usage/ of Debian to complement the costs with actual benefits -- as opposed to hypotheticals (such as compiling thousands of packages for arches without actual users). As it stands, 4 downloads for s390 appear somewhat disproportionate to 1,285,422 for i386. Dirk -- If you don't go with R now, you will someday. -- David Kane on r-sig-finance, 30 Nov 2004
Re: LCC and blobs
On Thu, Dec 16, 2004 at 02:23:54PM +0100, Martin Waitz wrote: > I have a PCMCIA card that lost its flash memory. > So suddenly its driver became non-free? Only if all such cards have lost their flash memory, which is improbable. As long as some cards exist with a working flash, the driver is useful without having to lug along non-free firmware. (There's a corner case: hardware which always ships with a firmware which does not work with the driver, and can be flashed by the user with firmware that does. This doesn't seem any less a dependency than when the driver itself has to load it; the only people the driver works for is those who have already manually installed the non-free data. I havn't thought too much about this case.) > What about all those drivers for hardware that I don't own? > They don't work for me, yet I won't flag them as non-free. The question is whether it works for somebody, not whether it works for you. > Sending firmware to the device is not that different to sending some > magic initialization commands. Firmware should be treated as exactly > that: magic initialization data for the device. "Magic initialization commands" are probably not copyrightable, so they're free; they're part of the driver, and cause no problems for anyone[1]. Firmware is (generally) copyrightable, and the license on the firmware affects the usability of the device and its driver to users. [1] there are some corner cases (of what seems to me to be copyright abuse), eg. in the AIM client case, but that's a very different scenario and should be treated independently. -- Glenn Maynard
Re: Bug#285518: misdn-utils includes a firmware loader
On Thu, Dec 16, 2004 at 12:02:30AM +, Jonathan McDowell wrote: > If we refuse to handle non-free firmware being loaded onto devices and > require they come with it already inside then we get to play the "I > can't see it, it doesn't matter" game, which gives the purists a warm > fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard > disc. > > This improves the experience for our users - they get to have the warm > fuzzy feeling too, knowing that in sacrificing the ability to use many > modern toys and gadgets they are purer of mind and body. Even better is > the fact that they doubley can't use the hardware because we're too busy > arguing about the firmware to make a release! No, there's a very concrete reason: given an installation of Debian main, the driver works. Drivers that require non-free firmware don't work out of the box; they say "sorry, for [legal|philosophical][1] reasons, we can include this driver but we can't completely the installation automatically like everything else; go hunt down the firmware and come back". Any other software doing that would go straight to contrib, but people want to make an exception for drivers. Your sarcasm and condescension make me wonder why you're here at all, though; you appear to regard Debian's founding principles with contempt. [1] depending on whether we're allowed to distribute the firmware at all: if the firmware isn't even in non-free, then it's a legal issue and philosophy doesn't enter into it. -- Glenn Maynard
Re: Linux Core Consortium
On Thu, Dec 16, 2004 at 02:46:53PM -0500, Ian Murdock wrote: > On Wed, 2004-12-15 at 23:55 +0100, Bill Allombert wrote: > > On Wed, Dec 15, 2004 at 02:36:52PM -0800, Bruce Perens wrote: > > > Bill Allombert wrote: > > > > But overriding them means we lose the certification ? > > > > > > We can't allow it to be the case that overriding due to an existing and > > > unremedied security issue causes loss of certification. There's no > > > common sense in that. > > > > Then could you elaborate the scope of the certification ? It is one > > of the main contender for me. I though the certification require to > > ship the exact same binary as provided by the LCC. > > The LCC will be pursuing its certification efforts through the > existing LSB certification process. The smaller ISVs will be more > willing to be flexible, so changes to the core that don't result > in loss of LSB compliance may be acceptable to them. We've heard > directly from the biggest ISVs that nothing short of a common > binary core will be viable from their point of view. So, > as with all things in this business, there will be tradeoffs > involved--you'll be free to make changes, at the potential > loss of some, though not necessarily all, ISV certifications. So Debian will help to build a certification that will ultimately discriminate against itself, so now proprietary software vendors have one more reason to not support Debian ? Alternatively, what would prevent the LCC to standardize on woody core (or sarge core when it came out) ? I mean, the core softwares the LCC is interested in are already present in several distros today, so probably it is possible to evaluate today what change e.g. sarge core would require to be acceptable as a core to the LCC ? That would certainly give us some ideas about where the LCC is going. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Bug#285518: misdn-utils includes a firmware loader
On Thu, Dec 16, 2004 at 10:51:39AM +0100, Frank Küster wrote: > When the issue of binary blobs in the kernel was first discussed here, > if I'm not mistaken the proposed solution was to rewrite the respective > drivers to be able to load the blob at runtime from "somewhere", and > that somewhere would then be populated from non-free or an external > source. And it was said that if the hardware device generally works > without firmware loading, just with worse performance, or if most > devices supported by the driver worked without, and just a minority > depended upon it, then the driver (the kernel module or monolitic > kernel) would be Free. Just to be a little clearer: drivers that require non-free firmware, but are under a Free license, are Free. Software which is not Free always goes in non-free. Software that is Free goes in either main or contrib. The active question, here, is not whether these drivers are Free; we're assuming they're Free, and asking whether they should go in main or contrib due to the firmware being non-free. -- Glenn Maynard
Re: GPL and LGPL issues for LCC, or lack thereof
This probably belongs on debian-legal, but let's go one more round on debian-devel given the scope of the LCC's potential impact on Debian. (Personally, I'm more interested in the question of whether agreeing to consecrate particular binaries contravenes a distro's commitment to the Four Freedoms than I am in the legal niceties; but I feel obliged to substantiate my earlier assertions.) As always, IANAL. [Bruce quoting the GPL] > However, as a > special exception, the source code distributed need not include > anything that is normally distributed (in either source or binary > form) with the major components (compiler, kernel, and so on) of the > operating system on which the executable runs, unless that component > itself accompanies the executable. Bruce> This does not require specification of the development environment. What part of "normally distributed ... with ... the operating system" is confusing? As written, this requires that any build requirement that doesn't come with the operating system must be available, in source code form, from the entity distributing the compiled Program. If the compiler required is some magic binary that isn't distributed with the operating system, then this clause isn't met. I will grant you that this clause was written in the days that commercial operating systems shipped with the C compiler bundled, and has since been interpreted to mean "as long as the development requirements are obtainable on the same terms as those needed to compile code in the same language, with similar functionality, that you wrote yourself" -- more or less. That's why I wrote "the letter of the GPL". What I expect from binary distributions of free software is that I can reproduce the binaries from the source code without undue effort, so that I can then exercise my freedom to modify it without debugging major functional regressions first. Given the complexity of a full GNU/Linux distro, I don't go around crying "GPL violation" every time something fails to build from source (or fails to work right when rebuilt). But I do think, based on the above-cited license text, that it's a technical violation of the GPL as well as a sign of poor software engineering process. me> Note that if Distro X distributes both NonFreeWareApp and glibc, and only me> offers technical support on NonFreeWareApp to those who don't recompile me> their glibc, then Distro X's right to distribute glibc under the LGPL is me> automatically revoked. Bruce> The word "support" does not appear in the LGPL. What Bruce> I do see is: Bruce> Bruce> Activities other than copying, distribution and modification are not Bruce> covered by this License; they are outside its scope. Bruce> Bruce> This would imply that support is outside the scope of the license. I don't Bruce> see any language in the LGPL specifying a support obligation of any kind. I'm relying on LGPL 6, which addresses distribution terms: As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. At first blush, I would expect "distribute ... under terms of your choice" to refer to the entire contract between "licensor" and "licensee" (if we are talking about software that is "licensed" and not sold; the common-law contract between seller and buyer is a whole different animal). If that contract includes a support clause, and the support clause does not permit modification of the work without loss of some of the economic benefits of the contract, then one could argue that this "exception" (from the requirement to offer source as per the GPL) should not apply, and that the distributor must either offer source or refrain from distributing the LGPL material. In fact, it depends on the legal regime that applies. Consider a recent (1999) decision of the U. S. 9th Circuit Court of Appeals, Sun v. Microsoft, which may be found at http://caselaw.lp.findlaw.com/data2/circs/9th/9915046.html (FindLaw is cool). The lower court had granted Sun a preliminary injunction against Microsoft's continued distribution of JVMs incompatible with Sun's Java standard. The appeals court vacated the district court's injunction, stating: [9] The enforcement of a copyright license raises issues that lie at the intersection of copyright and contract law, an area of law that is not yet well developed. We must decide an issue of first impression: whether, where two sophisticated parties have negotiated a copyright license and dispute its scope, the copyright holder who has demonstrated likely suc- cess on the merits is entitled to a presumption of irreparable harm. We hold that it is, but only after the copyright holder has established that the disputed terms are l
Re: Linux Core Consortium
On Thu, Dec 16, 2004 at 12:51:54PM -0800, Adam McKenna wrote: > On Thu, Dec 16, 2004 at 09:25:38PM +0100, Wouter Verhelst wrote: > > Op do, 16-12-2004 te 14:46 -0500, schreef Ian Murdock: > > > We've heard > > > directly from the biggest ISVs that nothing short of a common > > > binary core will be viable from their point of view. > > > > Well, frankly, I don't care what they think is 'viable'. > > > > 'ISV' is just another name for 'Software Hoarder'. I thought Debian was > > about Freedom, not about "how can we make the life of proprietary > > software developers easy?" > > Regardless of how you feel about proprietary software, it is someone else's > work and they are free to sell or license it as they see fit. I don't see > how someone advocating "freedom" can in the same (virtual) breath presume to > dictate what other people do with their work. I think Wouter is only asking for reciprocity here. If they don't care about his concerns why should he care about theirs ? Or alternatively "not caring" is a freedom. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Bug#286027: ITP: ms-sys -- tool for writing Microsoft compatible boot records
Package: wnpp Severity: wishlist * Package name: ms-sys Version : 2.0.0. Upstream Author : Henrik Carlqvist <[EMAIL PROTECTED]> * URL : http://ms-sys.sourceforge.net/ * License : GPL Description : tool for writing Microsoft compatible boot records Grabbed from homepage: This is a Linux program for writing Microsoft compatible boot records. The program does the same as Microsoft "fdisk /mbr" to a hard disk or "sys d:" to a floppy or FAT partition except that it does not copy any system files, only the boot record is written.
RE: Linux Core Consortium
>Unfortunally, some distributions don't seem to be willing to do more >than the minimal changes to adhere to the LSB. I did some patches for >RedHat - and the bugreport is still open (I don't know whether the >patches still work). Failing some required tests seems to be quite a motivator to at least taking a look. Barring that... *Officially*, when you certify a distribution to the LSB you're making a promise about conforming to the spec, and the test suites serve as an *indicator* of compliance (not proof: if you violate the spec and nothing in the test suites catch it, you still have to fix it), but in practice, people implement to pass the tests. >SUSE seems to try hardest to be LSB complient and Debian was rather >quick to implement my requests. I had no access to other distributions. >>Unfortunately, while we got spec contribution in this >>area, we didn't get matching code contributions: tests >>OR sample implementation. >> >(I think I'm ment with regards to the first two points.) Regarding the >latter, SUSE's implementation should completely fullfil the LSB >requirements (tough the init-functions may be a bit SUSE centric) >whereas Debian's system is also quite ok. (Though start-stop-damon >doesn't find out that my PERL script damon is running...) I didn't really mean to single you out, Tobias. There were a number of other contributors to the initscript spec section over time. >I agree with Mats that the best way to enforce init script support are >test cases. Seems that way.
Re: Are BLOBs source code?
Andreas Barth <[EMAIL PROTECTED]> writes: > Why should elf-aggregation always mean to be part of a derived code, and > fs-level aggregation mean that not? Even e.g. Linus writes that there > _are_ examples where elf-aggregation does not mean a derived work (well, > of course: the default assumptation is that it is derived, but it could > be proven otherwise). Is Linus a lawyer or is his stance backed up by a court decision? Assuming the answer is no (which I believe it is), what does it matter what Linus thinks on the matter?
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Wed, Dec 15, 2004 at 08:47:43PM -0600, John Hasler wrote: > Your script should check $PRERUNLEVEL. It will be N if you are booting. That's a nice idea, but do you know how fine it would behave with things like file-rc? Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Thu, Dec 16, 2004 at 09:32:08AM +0100, Javier Fernández-Sanguino Peña wrote: > > Well, you could have a message saying that you need to enable foo and a > 'force-start' action that started it regardless of what's in /etc/default. That might be a solution. Users would certainly be less confused, but some scripts they would have written would still be... > Moreover, the script could check if it's being called on startup (it's name > is 'S') and heed the default value and start anyway if called from the > command line. I think such a solution was suggested in an ancient thread, and it was concluded that it would not work with file-rc... > There are plenty of ways to avoid that confusion. There certainly are some workarounds, but my initial question is still unanswered: is it ok to remove the links if I did not create them but told the user how to create them? Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
On Thu, Dec 16, 2004 at 12:53:27AM -0500, sean finney wrote: > On Thu, Dec 16, 2004 at 12:34:21AM +0100, Nicolas Boullis wrote: > > But a user felt concerned that, in the future, he may remove the package > > and forget to delete the links. Then I thought I could remove the links > > in postrm on purge, considering they are part of the package's > > configuration (their absence being the default configuration). > > if the package is removed, the init script should just exit with 0 > status. removing the links during purge would also be appropriate. So you think lintian is wrong to complain? > you could also install the links by default, but have some other > variable in /etc/default/$package control whether or not it actually > starts (i think somebody else has mentioned this too). Yes, I know such solutions but don't like them much. But if "my" solution is proved to be wrong, I'll implement such a workaround... Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Thu, Dec 16, 2004 at 09:13:43AM +0100, Adrian von Bidder wrote: > On Thursday 16 December 2004 00.34, Nicolas Boullis wrote: > [de-installing run-level links that weren't installed] > > How about installing links as /etc/rc?.d/K??foo - so the links are there and > are properly manageable, but the init script will only be called as 'K??foo > stop' Unfortunately, athcool is not a deamon but a program that modifies some low-level configuration. Hence, running "/etc/init.d/athcool stop" actually does something (and might break the system) as badly as "/etc/init.d/athcool start"... I like the idea, but I'm afraid it's not appropriate for athcool, at least without reworking the init script... Cheers, Nicolas
Re: Linux Core Consortium
On Fri, Dec 17, 2004 at 01:13:11AM +0100, Bill Allombert wrote: > I think Wouter is only asking for reciprocity here. If they don't care > about his concerns why should he care about theirs ? Or alternatively > "not caring" is a freedom. We care because our priorities are our users and free software. Just because someone works for an ISV or develops on/for proprietary software does not make them a second class user. That said, I am not arguing for or against LCC, I just didn't like the tone of Wouter's e-mail, or the sentiment implied in it. --Adam -- Adam McKenna <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Linux Core Consortium
On Thu, Dec 16, 2004 at 05:07:44PM -0800, Adam McKenna wrote: > On Fri, Dec 17, 2004 at 01:13:11AM +0100, Bill Allombert wrote: > > I think Wouter is only asking for reciprocity here. If they don't care > > about his concerns why should he care about theirs ? Or alternatively > > "not caring" is a freedom. > > We care because our priorities are our users and free software. Just because > someone works for an ISV or develops on/for proprietary software does not > make them a second class user. What users ? There is no appearance the 'biggest ISV' that Ian mentionned are Debian users. If they were, they much certainly would support Debian in the first place so this discussion would be moot. > That said, I am not arguing for or against LCC, I just didn't like the tone > of Wouter's e-mail, or the sentiment implied in it. I see... Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: removing in postrm rc*.d symlinks that I did not create
On Fri, Dec 17, 2004 at 02:16:00AM +0100, Nicolas Boullis wrote: > > if the package is removed, the init script should just exit with 0 > > status. removing the links during purge would also be appropriate. > > So you think lintian is wrong to complain? no, i think lintian is correct to complain, but that you're also within reason to remove those symlinks if the package is purged. > > you could also install the links by default, but have some other > > variable in /etc/default/$package control whether or not it actually > > starts (i think somebody else has mentioned this too). > > Yes, I know such solutions but don't like them much. But if "my" > solution is proved to be wrong, I'll implement such a workaround... what's so bad about such a solution? i think it's simple to implement, easy to understand, and less prone to break. sean -- signature.asc Description: Digital signature
Re: removing in postrm rc*.d symlinks that I did not create
I wrote: > Your script should check [$PREVLEVEL]. It will be N if you are booting. Nicolas writes: > That's a nice idea, but do you know how fine it would behave with things > like file-rc? It should work fine. Note that this method _only_ controls script execution at boot time. If you also want to prevent the service from being started on a runlevel change you have to do something else such as checking $0. -- John Hasler
Bug#286037: ITP: ewiki -- ErfurtWiki is an implementation of the WikiWikiWeb hypertext system
Package: wnpp Severity: wishlist * Package name: ewiki Version : 1.02-1 Upstream Author : Mario Salzer <[EMAIL PROTECTED]> * URL : http://freshmeat.net/projects/ewiki * License : Public Domain Description : ErfurtWiki is an implementation of the WikiWikiWeb hypertext system ErfurtWiki is an implementation of the WikiWikiWeb hypertext system (written in the PHP scripting language). It allows everybody who comes along to edit and create new pages very easily. Ewiki package can be found at: http://mentors.debian.net -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.9 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1)
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen wrote: >> No; the hardware is damaged. No driver can drive that. The driver >> you have is a driver for Foomatic Quxer cards. You don't have a >> Foomatix Quxer; you have a broken pile of junk. > > So here you argue that because the firmware is gone the hardware is > broken, correct? No, I argue that because you've pried chips off the board, the hardware is broken. >> ... It's clearly software, and the driver clearly has a dependency on it. > > And now you consider it software just because the method of storage is > different? How can the nature of the bytes change because they are > stored on a disk? The nature of the bytes do not change. But my name, distributed in a Debian package, is software. My name, written in letters of granite thirty feet high, is not. How can the nature of the data change? Architectural plans for a house, shipped in a Debian package, are software. An actual house embodying those plans is not software. But gosh, the nature changes! > If the driver need to load the firmware or just needs to enable it is > the same thing. Just think of the enable sequence as highly compressed > firmware > :-). The simplest and most important difference is that we know anyone with a functioning device has the on-chip firmware. He often can't redistribute the on-disk firmware to somebody else if he sells the device, as its licence prohibits this. > So the driver has a dependency on the firmware, even if it is in the > device itself. So we have to move all drivers that use devices with > build-in firmware to contrib. > > That or we see that the firmware is actually part of the hardware and > that uploading is just a natural thing a driver should do. Some firmware is part of the hardware. Some isn't. It's easy to tell -- either it's in the hardware or it isn't. Of course, the name "firmware" should make it clear that this is an often ambiguous line. But this does seem to be a good practical place: can anybody with the device and the driver use it? Or are there some people who even with a functioning, complete device and a driver who can't get it to work? > The fact that most firmware cannot be redistributed or does not come > as source just selects what we can ship or have to ask the user to > provide. > >> Since in the case of firmware on disk we can't reliably get the >> firmware to users *anyway*, utility's not atainable and we should keep >> our principles of freedom. > > I see no limitation of my freedom in using firmware. Please tell me > how I am limited in my freedom. If I wanted a open source firmware I > could buy a device with open firmware, Then Windows isn't proprietary either. Sigh. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: Bug#285518: misdn-utils includes a firmware loader
Glenn Maynard <[EMAIL PROTECTED]> wrote: > No, there's a very concrete reason: given an installation of Debian > main, the driver works. Drivers that require non-free firmware don't > work out of the box; The vast, vast majority of drivers require non-free firmware. > Your sarcasm and condescension make me wonder why you're here at all, > though; you appear to regard Debian's founding principles with contempt. Jonathan believes (as I do) that you're choosing the wrong place to draw an arbitrary line. He has chosen to express this opinion via humour. Given all that he's done for Debian at various points, suggesting that he shouldn't be here is really going too far. -- Matthew Garrett | [EMAIL PROTECTED]
Re: LCC and blobs
On Thu, Dec 16, 2004 at 09:20:14PM -0500, Brian Thomas Sniffen wrote: > Peter Van Eynde <[EMAIL PROTECTED]> writes: > > > Brian Thomas Sniffen wrote: > >> No; the hardware is damaged. No driver can drive that. The driver > >> you have is a driver for Foomatic Quxer cards. You don't have a > >> Foomatix Quxer; you have a broken pile of junk. > > > > So here you argue that because the firmware is gone the hardware is > > broken, correct? > > No, I argue that because you've pried chips off the board, the > hardware is broken. Er, no. Flash can be overwritten with invalid data (eg. nulls or interrupting a flash process), rendering drivers that expect a working flash to not work. It's not correct in the general case to say that "no driver can drive that"; some hardware can still be re-flashed to correct the data, so a driver that does have a (usually redundant) copy of the firmware and code to upload it can, in fact, drive the device. However, unlike non-flash devices that need the firmware uploaded every time, the driver is still useful without it. Whether or not the "misflashed hardware is a broken device" analogy is bought, the fact remains that many copies of the hardware still do function, having working firmware. The existance of non-working hardware is irrelevant. -- Glenn Maynard
Re: Bug#286027: ITP: ms-sys -- tool for writing Microsoft compatible boot records
On Fri, Dec 17, 2004 at 01:24:06AM +0100, Bartosz Fenski aka fEnIo wrote: > * Package name: ms-sys > > [...] > > This is a Linux program for writing Microsoft compatible boot records. The > program does the same as Microsoft "fdisk /mbr" to a hard disk or "sys d:" > to a floppy or FAT partition except that it does not copy any system files, > only the boot record is written. Where is the included boot block code from? I'd also like to point out that the boot block source code is not included, certainly making this package non-DFSG-free, and probably making it undistributable by us under the GPL. -- gram
Re: Bug#285518: misdn-utils includes a firmware loader
On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote: > Glenn Maynard <[EMAIL PROTECTED]> wrote: > > > No, there's a very concrete reason: given an installation of Debian > > main, the driver works. Drivers that require non-free firmware don't > > work out of the box; > > The vast, vast majority of drivers require non-free firmware. Hmm. A few places to draw the "dependency from driver to firmware" line seem to be: 1: a dependency exists if the driver needs access to a copy of the firmware (for devices that need the firmware uploaded on every boot); 2: a dependency exists if the hardware needs firmware at all; 3: a dependency never exists. My "don't work out of the box" statement is based on #1: hardware that requires non-free firmware to be uploaded every time will not work out of the box in Debian (unless the installer is smart enough to pull non-free firmware packages from non-free, which, in my opinion, would be a good thing to do when possible, regardless of where the drivers end up). Your "vast majority" seems to be based on #2: most hardware does employ firmware, but (at least among the hardware that I've used) does not require it to be uploaded every time the device is initialized. (I don't have any hardware in #1, except possibly my nVidia hardware--I have no idea what those drivers are doing.) -- Glenn Maynard
Re: removing in postrm rc*.d symlinks that I did not create
I wrote: > If you also want to prevent the service from being started on a runlevel > change you have to do something else such as checking $0. Init exports RUNLEVEL, PREVLEVEL, and INIT_VERSION. Thus INIT_VERSION will be set if you are booting or changing runlevels. -- John Hasler
Re: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?
Jay Berkenbilt wrote: > I've sent messages to various [EMAIL PROTECTED] addresses many > times for various reasons, and they have all always been ignored. Me too, for values of ignored that include "may have resulted in some action, but never got a reply email". I think that we need BTS pseudo-packages for the autobuilders. -- see shy jo signature.asc Description: Digital signature
Re: LCC and blobs
[just some minor additions.] > On Thu, Dec 16, 2004 at 09:20:14PM -0500, Brian Thomas Sniffen wrote: > > No, I argue that because you've pried chips off the board, the > > hardware is broken. On Thu, Dec 16, 2004 at 09:39:59PM -0500, Glenn Maynard wrote: > Er, no. Flash can be overwritten with invalid data (eg. nulls or > interrupting a flash process), rendering drivers that expect a working > flash to not work. And some monitors can be driven in ways that cause them to burn out. In both cases, there's a change in the electrical characteristics of the device which renders it non-functional. > It's not correct in the general case to say that "no driver can > drive that"; some hardware can still be re-flashed to correct the data, > so a driver that does have a (usually redundant) copy of the firmware > and code to upload it can, in fact, drive the device. In principle (depending on the board design), the flash data can be pulled off the device. We don't have to distribute the data to allow users to reflash their devices. [And, in the general case, we probably shouldn't -- because we're not set up to track all the potential hardware changes, and we're not in a position to make sure we're providing the proper version of the data for the instance of hardware that the user has. Of course, we'd also get it right in a number of cases.] Fundamentally, the DFSG is aimed at making sure that we can provide the software that we can support. Restrictions that leave us writing an opaque blob of bits which drives an unknown API very much put us into a context where we can't know that we're doing the right thing. > However, unlike non-flash devices that need the firmware uploaded > every time, the driver is still useful without it. Yes. > Whether or not the "misflashed hardware is a broken device" analogy is > bought, the fact remains that many copies of the hardware still do > function, having working firmware. The existance of non-working > hardware is irrelevant. Exactly. -- Raul
