Software Modem Driver
by Warren Togami
https://bugzilla.fedora.us/show_bug.cgi?id=1803
slmodem package
I recently was forced to endure the pain of using dial-up Internet. I
was surprised to find this "slmodem" daemon that uses the ALSA
snd-intel8x0m driver included in FC2 to make a working sound device,
avoiding the binary-only kernel module. The slmodemd daemon creates
/dev/ttySL0 and ppp worked great. The current package works, but if
anyone else is interested in polishing this up, it needs a bit more work.
Blockers:
* Add command line option to demonize
* Return useful error codes, or zero if daemonize worked
* Use "daemon" so messages are recorded in syslog
* Make [OK] and [FAILED] messages work
* Add /etc/sysconfig/slmodem for country configuration, and perhaps
other options. See Mandrake's slmodem package for examples.
Would be nice:
* Use ppp's "chat" program to test modem with ATZ and OK response
* Would it be acceptable to automatically symlink /dev/modem to
/dev/ttySL0 if /dev/modem does not exist?
* Does selinux policies need to know anything about this?
License question:
* The license attached is included within the tarball. If used with the
binary-only kernel it probably would be unacceptable to ship, but it
appears that the daemon has an acceptable license? BSD-ish with
documentation advertising requirement?
Warren Togami
wtogami(a)redhat.com
/*
*
* Copyright (c) 2001, Smart Link Ltd.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
* 3. Neither the name of the Smart Link Ltd. nor the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*/
19 years, 9 months
Tetex inter-dependencies: proposed changes
by Leonard den Ottolander
Hi,
I've been looking a bit at the inter-dependencies that exist between the
different tetex packages. F.e. the fact that tetex-xdvi currently needs
tetex (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11721).
All this is caused because not all files have been moved into the
correct packages. For some files this is rather obvious, for others it's
more tricky to establish to which package they should belong.
My proposal is to move a couple of files from the other tetex packages
(mainly from tetex itself) to tetex-fonts, in essence making tetex-fonts
a kind of tetex-common package. However no name change or split off is
necessary.
Dependencies would then become as follows:
tetex, tetex-dvips and tetex-afm require tetex-fonts
tetex-xdvi and tetex-latex require tetex-dvips
(doesn't tetex require tetex-dvips? If it does drop dependency on
-fonts, and -latex's dependency on -dvips.)
tetex-latex requires tetex
(need to investigate tetex-afm a little more)
Changes to /usr/share/texmf:
- All fonts, including sources and japanese (from tetex-dvips) fonts to
tetex-fonts (/usr/share/texmf/fonts/*). Sources are needed to generate
font definitions in /var/lib/tex.
- /usr/share/texmf/fontname to tetex-fonts (not really necessary, but as
tetex-fonts is the central package this is probably a good idea).
- /usr/share/texmf/xdvi/XDvi is required by tetex, so can't move to
tetex-xdvi. Move to tetex-fonts so it's available to both tetex and
tetex-xdvi.
- Parts of /usr/share/texmf/web2c to tetex-fonts, namely mf-nowin.base,
mf.base, mf.pool, mfw.base, plain.base, mktex.opt, mktexdir,
mktexdir.opt, mktexnam, mktexnam.opt and mktexupd. Necessary for
creation of font definitions in /var/lib/texmf.
- All .cnf and .cfg files to tetex-fonts.
Changes to /usr/bin:
- Move the following binaries to tetex-fonts (all but mfw from tetex):
MakeTeXPK, access (needed by texhash), fmtutil, gftodvi, gftopk, gftype,
gsftopk, inimf, kpsepath, kpsestat, kpsetool, kpsewhich, kpsexpand, mf,
mf-nowin, mft, mfw (from tetex-xdvi), mktexfmt, mktexlsr, mktexmf,
mktexpk, mktextfm, ps2pk, texhash(required by %post scripts) and virmf.
Necessary for creation of font definitions in /var/lib/texmf.
Changes to docs and man pages:
- kpathsea and web2c info to tetex-fonts
- relevant man pages to tetex-fonts
Other changes:
- libkpathsea.a and /usr/include/kpathsea headers to tetex-fonts
(separate tetex-devel package?).
- Cron job to remove unused font definition files to tetex-fonts.
- /usr/share/texmf/ls-R and /var/lib/texmf/ls-R files to tetex-fonts.
The above changes fix xdvi's dependency on tetex. A spec file (for FC 1)
can be found attached to the above bug report. It's quite possible a few
more files need to change packages before this is entirely correct. To
test correctness of this spec file the various /var/lib/texmf/
directories need to be removed so they can be regenerated on (first)
invocation of xdvi (or other programs). Dependencies for tetex-afm might
not yet be satisfied (if they are please let me know).
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
19 years, 9 months
RE: Submission process (was: Re: Self-Introduction: Michael Tiemann)
by Erik LaBianca
>
> ...and if only bugzilla could be avoided for the submission process,
and
> replaced by a more comprehensive system, it would help a lot. Or maybe
> just customize it enough to make it unrecognizable? ;-)
>
Is there any sort of system out there that's already written and comes
even close to doing what is needed? The fact is that learning bugzilla
was daunting for me as a new user, but given the alternatives I must say
it works quite well.
I do know that writing a complete custom app to handle the workflow
would be a pretty significant project to do correctly. Theres no point
in doing it half-ass, as bugzilla at least allows a lot of flexibility.
I think a few automation tools connecting to bugzilla is probably the
ticket to success. Fedora-startqa for instance queries bugzilla, and
automatically finds the most recent SRPMS and MD5Sums and downloads
them. It wouldn't be much harder to write an automated submitter, in
fact I think it's already been done (ESR's tool?).
I would say an automated submitter needs to be coupled with a pretty
strong automated build checking and rpmlint type tool though, in order
to prevent people from just running fedora-submit
"my_lame_non_compliant.src.rpm" and making extra work for QA.
Fedora-startqa has a lot of these automated checks in it, but is
dependant on mach currently.
--erik
19 years, 9 months
Signing an rpm package at build-time automatically
by Didier Casse
Hi there!
When we built a package, we can sign it at build time by issuing
the command:
rpm -ba --sign file.spec
and it will prompt for something like this:
Enter pass phrase: <passphrase> (Not echoed)
Now on my system I need to build rpm automatically ( without human
intervention)! Is it possible to have my paraphrase being read in a file
rather than me sitting in front of the computer and actually typing it?
I know it's not a very good idea but my rpms need to be generated
automatically daily via cron, and I can't sit behind my pc and type the
paraphrase each time one rpm is being built.
Can I avoid the prompting of the paraphrase if I want to sign my packages
at build-time and everything be done automatically? Thanks.
This is for the purpose of a repository and things like these need to be
automated when dealing with multiple packages.
With kind regards,
Didier.
---
PhD student.
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: didierbe at sps dot nus dot edu dot sg
Web: http://ssls.nus.edu.sg
19 years, 9 months
Re: Submission process (was: Re: Self-Introduction: Michael Tiemann)
by "Nils O. Selåsdal"
On Wed, 2004-06-30 at 18:00, Michael Schwendt wrote:
> On Wed, 30 Jun 2004 14:58:56 +0200, Rudi Chiarito wrote:
> At fedora.us, further QA policy changes are in the queue. One which allows
> for new packages to enter the "unstable" repository after a very basic
> review (in particular the security relevant checks) and then hope that the
> community reports any missing flaws. But even then, the packagers ought to
> make sure their packages build at least on all the target platforms and
> adhere to the packaging guidelines, too. The packagers themselves should
> do a good portion of the QA for their packages. For instance, there is
> documentation on how to use 'fedora-rmdevelrpms' or 'mach' to find missing
> build dependencies. And there are several other packaging topics covered
> in the Wiki, too.
Which btw reminds me, is where can I get a mach configurations for FC2 ?
19 years, 9 months
RE: Submission process (was: Re: Self-Introduction: Michael Tiemann)
by Erik LaBianca
>
> > I'll admit that some of the trouble is more imaginary than real:
five
> > minutes spent copying, pasting and double-checking can easily seem
like
> > an eternity, when it's actually a mere five minutes... but why waste
> > them, if it can be avoided?
>
> You cannot avoid human interaction as in setting bugzilla keywords and
> replying to comments. You could only avoid that with ultimately
trusted
> package maintainers who get direct access to a build/publish system.
>
Absolutely true, although I believe the current system is still daunting
for a new packager or reviewer. I'm not sure how to make it less so
without compromising quality other than saying that people need to just
jump in, and ask for help on the list if needed.
Would there be some benefit to having a separate list for Extra's
discussion?
>
> No. It's in fedora.us already in the "stable" repository (much to the
> disliking of some people) and the fedora.us build system uses a
modified
> version, http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/
> but that is not an automated build system.
>
> > Should it be sanctioned as a required tool for packagers?
>
> No, because it behaves differently than plain rpmbuild.
>
Nonetheless, we really need to have a build environment that's >easily<
available for prospective packagers and QA testers to build packages on.
I propose mach, but a lot of people don't like it. Redhat has an
internal build system. Are there plans to release it
It's been a couple months since I was last harping on the list for some
feedback from the powers that be at RedHat regarding the official Fedora
Extra's infrastructure. Has there been progress? This issue really needs
to be resolved, even if the resolution is "we will eventually take over
the fedora.us infrastructure as it stands and abide by the policies
decided upon by the fedora.us community" or the other extreme of "we
don't like the idea of an official Fedora Extra's after all, do your own
thing", or more likely something in between.
--erik
19 years, 9 months
Packages need rebuilding for openldap
by Tim Waugh
Looks like these packages need rebuilding to pick up the new openldap
soname:
libuser
autofs
sendmail
kdebase
cyrus-sasl
nss_ldap
samba
gnupg
Tim.
*/
19 years, 9 months
automating fedora installations with xslt
by Erik Sjölund
I just wanted to present an installation system for fedora that
could be used to administrate a whole network of fedora/redhat linux
computers. It uses xslt to generate rpm packages, grub files, kickstart
files and html documentation out of the configuration in xml format.
The generated rpm packages are used to deliver out configuration files
to the hosts.
Homepage: http://xml2hostconf.sourceforge.net
License: GPL
I would be really interested to hear what other installation and
configuration frameworks there are out there and what is being used.
cheers,
Erik Sjölund
19 years, 9 months
GIF support
by Andres Petralli
Hi Everyone,
I'm interested in knowing when GIF support will be re-included into
packages like PHP, ImageMagick and other image processing and
generation tools. GIF, as you might know was covered by patents until
the 20th of June 2004. The patents are now expired worldwide and gif
code could be easily re-activated in libs like GD and PHP. It was
always there, it was just not included into the packages because of the
patent problems. So, are there any plans to include gif libs into any
packages? It would be great if someone could give me some feedback on
this.
Thanks,
Andres
--
Andres Petralli
In der Wässeri 43
CH-8047 Zürich
andres(a)petralli.com, +41 43 3218066, +41 78 8353537
ICQ: 4685081, MSN: apetralli(a)msn.com, FAX: +41 43 5349810
19 years, 9 months
Self-Introduction: Michael Tiemann
by Michael Tiemann
1. Michael Damian Tiemann
2. USA, Chapel Hill, North Carolina
3. VP, Open Source Affairs (and former hacker)
4. Red Hat, Inc. (in Raleigh)
5. My goals are to push some extra useful packages that are built for
other or ancient distros into Fedora Extras. These packages are ones
that I believe will greatly expand the relevance of Fedora as a
development platform because of the additional communities they bring
with them. In particular:
* revive blender3d for FC2/Extras (was in FC1/Extras)
* add support for the R language (see http://www.r-project.org/)
* bring GRASS to Fedora (FreeGIS has been funded to do this)
* bring in the latest and greatest free bioinformatics sw
* see if the new eGroupware stuff is ready for FC2/Extras
As for doing QA, I can certainly do sanity checking of packages that
I've built or that others have built but not published to Fedora.
6. Historical qualifications
* A long time ago in a galaxy far away, I was a GCC hacker
* I know C, C++, and can parse bash, perl, and many other languages
* You should trust me because (1) Christian Gafton knows how to find me
(I work in the same building) and (2) Warren Togami brought me macademia
nuts from Hawaii
7. GPG KEYID and fingerprint:
[tiemann@localhost tiemann]$ gpg --keyserver pgp.mit.edu --fingerprint
ea0ac0e4
pub 1024D/EA0AC0E4 2003-08-14 Michael Tiemann (CTO, Red Hat)
<tiemann(a)redhat.com>
Key fingerprint = F0AD 3368 D24A 56CD A2AD 6A12 CAB3 2E89 EA0A
C0E4
sub 1024g/BB6171EB 2003-08-14 [expires: 2008-08-12]
M
19 years, 9 months
