Re: If you really want Free firmware...

[Bluefuture]

Try to take a look to this http://lists.duskglow.com/open-graphics/
about problems, solutions and ASIC vs FPGA proposed for a real project
to build a open design 2d/3d graphic card.

Cheers,
Blue.

Re: If you really want Free firmware...

[Bluefuture]

Another interesting link is Electronic Design Automation (EDA) software on 
Linux: http://www.linuxeda.com/

Cheers,
Blue.

dehs will stop

[Bluefuture]

After another gruelling discussion on #debian-devel about the useless of
dehs and the lack of watch file (75,60% of non native debian packages
doesn't had one), I think that dehs is start to begin only my own
personal toys, so i'm thinking to stop it and to leave alioth resources
and put my development effort on something more useful to the community.

I know that there are a little bit group of people that think that the
"old" use of watch file could be converted in a Qa tools, but actually
i'm the only one that is trying to find a solution that could fix that
lack of watch file. 
But without maintainers interest, the project still lack in an usable
status. 
There is no reason to put more work and effort on a community tool that
community itself consider useless.

I hope that something could change. But i don't belive it.

Cheers,
Stefano


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dehs will stop

[Bluefuture]

>I know that I thougt dehs per se not too useful, but the watch section
>on qa.d.o has inspired me to write watch files for two of my packages.
>Not much (2 out of 7), admittedly, but I think that it's fairly useful.
>I think the experimental columns are overkill (as people packaging
>experimental stuff probably monitor upstream releases even more
>closely).
>If 25% of the packages can be watched, hey, that's a fair share.

Are we still talking around dehs as a personal  developer tool?

Is It a so hard work to add this watch file, only as an example for some
of your package i had built it in some minutes:

xml2

version=2
http://download.ofb.net/gale/xml2-([\d\.]+)\.tar\.gz 

xtermset
--
version=2
ftp://ftp2.sf.net/pub/sourceforge/c/cl/clts/xtermset-([\d\.]+)\.tar\.gz

ferm
---
version=2
http://ferm.sourceforge.net/ferm-([\d\.]+)\.tar\.gz

If we still think to fix watch file only for application that we doesn't
strictly follow this will not help dehs. You must fill every file watch
for everyone of your package that had a valid upstream and acessible
repo. We all know naturally some exceptions like only as example if
there aren't available tarball releases/snapshot but u build your
package from cvs/svn/arch.


Tanks,
Stefano


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: dehs will stop

[Bluefuture]

>The community might start considering it less useless if an
>explanation of what it is supposed to be good for was actually
>available. In particular, why should a maintainer care about watch
>files if he uses something else than uscan to keep track of upstream
>happenings?

>From time to time, these little microthreads start on d-d where
>somebody complains that so and so many packages do not have watch
>files, but it seems always to be left entirely to the reader's
>imagination to figure out why that is apparently a bad thing.
>If I go to, say,  in search of
>information, I find not a single word of purpose or rationale.

>The only places I can see watch files mentioned in our general
>"required reading" documentation (twice in NM-guide and once in
>dev-ref), they are presented exclusively as a maintainer convenience
>tool.

>If people don't care as much about this as you think they should,
>perhaps it would be a good idea to try explaining why they *should*
>care, instead of just lamenting their lack of a telepathic
>understanding of your intentions?

This is not true. Had u tried to do a search about dehs/watch on debian-devel 
about 2004/2005?

I'm not a debian developer, so i could not post on dda mailing list. I
had opened many thread over this months on debian-qa debian-devel about
dehs issues. The only reply are:

1) Dehs is useless.
2) Submitting 6229 wishlist bug is not possible/is not the solution
(without proposing alternatives method)

I had try to randomly submit wishlist bugs for 6 packages to bts with
the tag "patch" pointing to the dehs site or attaching the watch file to
the bug.
Almost all of this bug was closed and the watch file was check (in some
cases fixed) and inserted in the package on the next upload. 

If the watch file is well done - preferring ftp and http download
address instead of html pages - dehs try to catch in his archive also
the UPSTREAM changelog/news as you can see here[2] clicking on the
upstream version. 
So we (all other user and developer that doesn't maintain the package)
can check features and upstream bugs fixed in the new
usptream release and the upstream bugs that we still had in debian and
features we doesn't had for packages that are not in sync with upstream
version or that ones that the maintainer had not packaged for more then
one
release. 
So we can start to check things like maintainer activity, vacation, mia,
see if the maintainer is simple too busy (we will could add in future in
dehs archive the upstream release date field and the debian package
upload date - for this task we need some collaboration from the uscan
developer). Then after this check, if we doesn't had a clear situation
about the upstream  we could email to the maintainer what is the problem
about packaging the new version (if months has passed from the upstream
release and the maintainer doesn't has prepared uploaded the package in
debian). 
We could have for reply that the new release is not in a good
and stable shape, or that he need a library not already packaged in
debian etc. etc.
I think that also monitoring upstream bugs fixed, and new feature we
could make a better distro and not only fixing bugs and put in an
harmonic shape all the packages
in debian but also getting what the upstream authors offer to debian and
to the all the linux distros with his upstream releases and development
work. 

[1] http://dehs.alioth.debian.org/no_updated.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

dehs-devel mailinglist

[Bluefuture]

I had opened a dehs[1] development mailing list[2] on alioth to
coordinate issues and work.
Anybody want discuss ideas, improve or work on dehs an watch file system
could subscribe to the list[3].

Thanks,
Stefano

[1] http://dehs.alioth.debian.org
[2] [EMAIL PROTECTED] 
[3] http://lists.alioth.debian.org/mailman/listinfo/dehs-devel



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

try to keep a watch file into your package

[Bluefuture]

The dehs system now is regular running again every two days on  alioth
(and so also on the info feed to developer.php on qa). 
Looking at no_watch page[1] there are:

Total source packages without watch file: 6324 
Total source packages: 8285 
%:  76,33%

But seems also that there are:
1621 packages that had no watch filel had a dehs automatic generated
watch file that had passed uscan test.
If every developer could download, check and if necessary fix the
automatic generated watch file and the put the file in his package
source we could fix the info in developers.php and the status on dehs
for some of the 6324 packages without watch file. 
Every developer could find his automatic generated watch file going on
his dehs own maintainer/package page from dehs homepage[2] on alioth. 

Cheers,
Blue


[1]http://dehs.alioth.debian.org/no_watch.html
[2]http://dehs.alioth.debian.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: try to keep a watch file into your package

[Bluefuture]

Il giorno mar, 25-01-2005 alle 07:49 +0100, Goswin von Brederlow ha
scritto:
> Bluefuture <[EMAIL PROTECTED]> writes:
> 
> > The dehs system now is regular running again every two days on  alioth
> > (and so also on the info feed to developer.php on qa). 
> > Looking at no_watch page[1] there are:
> >
> > Total source packages without watch file: 6324 
> > Total source packages: 8285 
> > %:  76,33%
> 
> What is the number if you exclude native packages?
Native packages are already not included in the dehs system.
> 
> MfG
> Goswin
-- 
Bluefuture <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: try to keep a watch file into your package

[Bluefuture]

Il giorno mar, 25-01-2005 alle 13:56 +0100, Wouter Verhelst ha scritto:

> I'm not convinced having a watch file is always useful.
> 
I agree with you.
> I would hope a maintainer would follow the announcements of the software

I agree with this. Dehs/Watch is not a system for bypassing upstream
mailing list, announcement, chat.

> he packages and upload only its latest stable upstream version, as
> opposed to just "the latest version", whatever that may be; and that the
> maintainer would only upload a new upstream version if the change is
> meaningful (for instance, if a new upstream version only includes
> changes relevant for, say, the FreeBSD and Microsoft Windows ports of
> their application, it's useless to upload the latest version). If there
> are other (more detailed and reliable) ways of finding out what the
> latest upstream version is, having a watch file isn't really necessary.
> 
As you can see on alioth pages, dehs, for packages with a valid (or
automatic generated watch file) "try" to keep the upstream
changelog/news from the new upstream version not in sync with debian
version, as you can see by clicking upstream version number (where
available)[1] or on your maintainer/package page on dehs.alioth. 
> As another point, I myself have become the upstream maintainer of the
> NBD tools since about a year now, IIRC (while I have been maintaining
> packages for NBD since July 2001 or so). I could have changed the NBD
> packages to be native ones, but I opted not to do so; however, since I
> release them myself, I'm quite aware when there is a new NBD upstream
> package. Having a watch file is unnecessary bloat, then.
> 
In this cases watch file (if the package doesn't become native) could be
intended as an info tool for debian user community and for all other
developer that are not the maintainer or the upstream author of your
package (this is another goal of dehs i hope).

> These are just two examples where having a watch file isn't really
> necessary; I can imagine that there are a lot more. That's not to say
> that your effort isn't appreciated or that it is even completely
> useless; only that it is to be remembered that a watch file, while often
> useful, isn't always necessary and might in some cases even be a bad
> idea. Considering the above, if 76% of packages do have a watch file and
> the other 24% do not, it might be reasonable to assume that a high
> number of those that do not yet have a watch file do not actually need
> one.

The problem is that 76% of packages doesn't had a watch file and only
the 24% had one.

> 
> Of course, as I said, this does not have to mean that /none/ of those
> packages actually do not need a watch file; in fact, I just downloaded
> the automatically generated watch file for one of my other packages
> where a watch file /is/ useful (since the upstream maintainer doesn't do
> announcements) ;-)
> 
There is always, as above, the second Dehs goals as an info tools for
user and other developers that doesn't maintain your package and for
this reason doesn't follow the upstream mailing list/announcement
developing activity.

Cheers,
Blue

[1] http://dehs.alioth.debian.org/no_updated.html



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: try to keep a watch file into your package

[Bluefuture]

Il giorno mer, 26-01-2005 alle 09:02 +0100, Free Ekanayaka ha scritto:

> Thanks for this effort.
> 
> Would it make  sense to support  queries  of dehs  by maintainer email
> address?
> 
> This ways it would be  easier for people  to check the status of their
> own packages.

This functionality is already implemented at http://dehs.alioth.debian.org

Cheers,
Blue


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: try to keep a watch file into your package

[Bluefuture]

>What do you do with packages that have uncooperative upstream and thus
>a watch file is not possible?
>
>apg's web host, for example, doesn't support directory listings, so I
>had to resort on checking the fingerprint of the download web page to
>find out whether there is a new release.
>
>Greetings
>Marc

If there is no way, other than following mailing list, to know upstream version 
and the upstream author doesn't want to help you 
there is no way for dehs to follow upstream release, but this is not the case 
of apg. I think that this watch file works fine:

version=2
http://www.adel.nursat.kz/apg/download.shtml  download/apg-([^b]+)\.tar\.gz 
debian uupdate

Cheers,
Blue


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Debian as living system

[Bluefuture]

Actually debian has three distro "level": unstable testing and stable.
There are some policy for packages entering in testing but for stable we
must to go "on freeze when ready" and fix all remain rc bugs before
release. With this proposal i want to remove the release concept but we
need some infrastructural changes.

- We must improve and doesn't trash tests made in unstable:

A new upstream package could enter in unstable only if the actual package 
in unstable isn't old more than "testing waiting time"/2 or if the upstream 
release fix some rc bug in the actual package in testing.

- We must to use this same policy adding the normal unstable to testing
policy from testing to stable using a "stable waiting time" that could
be fixed to 30/60/90 days according to the priority (and eventually
section) of the packages.

So we cannot have entering two different packages in stable less than 30
days in the optimal case when also dependency are old enough and rc bugs
free. If a security bugs comes out when a packages is in testing will be
opened an rc bugs in testing or also in unstable if needed. If we have a
security bugs when the package land in stable we fix trough
stable/updates. 

So we will have a very slowly stable release moving without the needs of
formal freeze and releases: a "living" system.

Official cd are daily (or weekly) rebuilded snapshots of the stable
distro or net installable cd images.

The wiki of to improve the proposal could be find here[1].

Cheers,
Stefano

[1] http://wiki.debian.net/?LivingSystem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Re: Debian as living system

[Bluefuture]

> > - We must improve and doesn't trash tests made in unstable:
> 
> Why do we need to do that? A package which is clearly  improved or outdated
> does not need any testing.

Because, for example if i release three revision of a package in a month and i 
upload in unstable,
it is in a good status with no rc bugs, still must waiting two days for 
entering in testing, but i override
it uploading the new upstream version package then i must restart to testing 
the new upstream version in unstable without
having the old version entering in testing and probably maintaing an old one in 
testing untill the new upstream packaged
version is in a good shape and is old enought for land in testing.

> > - We must to use this same policy adding the normal unstable to testing
> > policy from testing to stable using a "stable waiting time" that could
> > be fixed to 30/60/90 days according to the priority (and eventually
> > section) of the packages.
> 
> We dont change stable, this does not work you can only test the system as a
> whole.
> 

Actually we doesn't change stable, but with the new infrastructure we can start.
I think that a system could be tested with a group of packages an its 
dependencies.
Big infrastructural changes (as a new install system) could be done of the 
stable system and land in stable when done.
Stable, testing and unstable could has different infrastructures and cd 
snapshot so that infrastructural changes land 
one by one in stable only when ready.

> > So we cannot have entering two different packages in stable less than 30
> > days
> 
> sure we can.
This was an assumption of not to have too many frequent software changes in 
stable.
Probably if i have Inkscape installed and i'm running stable also if upstream 
release a new version every week
in the optimistic use cases i cannot must to use a new version of it less then 
30/60/90 days following the testing to 
stable policy.

> 
> > So we will have a very slowly stable release moving without the needs of
> > formal freeze and releases: a "living" system.
> 
> Kind of cancer?
Not only to do thinks slowly with little changes without having a total 
different os and applications after one/two 
or three year of upstreams work impact to the distro users.
> 
> > Official cd are daily (or weekly) rebuilded snapshots of the stable
> > distro or net installable cd images.
> 
> And you cant do QA nur security update, create additional mirror load on
> stable and kill cd distributors.
Security updates are done through security/updates if u done daily cd rebuild u 
have the last security updates 
on the cd every day if u want to do a new install. After installing a day X 
snapshot you can follow
day x+n security updates through security.debian.org.
> 
> I think you can do that for non-core packages like bsd packages, but the
> base system must be released as a whole.
For base system we could create something like a group or branching levels 
using some dependencies info 
so it can land to stable only as a whole. 

Greetings,
Stefano


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

pmount vs updfstab

[Bluefuture]

Actually Ubuntu Linux uses pmount:

pmount is a wrapper around the standard mount program which permits
normal
users to mount removable devices without a matching /etc/fstab entry.
Together
with hal and gnome-volume-manager (or similar programs) this will
provide
fully automatic device handling without user intervention.

Do we have a "debian solution" about this issue? Or we want to use
updtfstab? I tink actually Debian doesn't has any "official solution".
How we can use pmount on a Debian system?

Cheers,
Blue