Time for a new kernel?
In my opinion, Linux would not be where it is today without Debian. RedHat may have convinced businesses to use Linux, but Debian really convinced everyone else to not only use Linux, but to like it. The decisions Linux kernel devs now make are from the angle of getting and keeping customers. It is no longer about quality or security, but revenue. As a result they are making choices which make the community very unhappy, such as 'systemd' to name only one. Maybe it is finally time to consider moving the core system to another kernel. Debian is by far the most wide spread implementation of the GNU operating system, so if only the kernel were replaced, the rest would still work as we al like it to. (This is evident with Debian GNU Hurd & kFreeBSD projects). The only real hurdle would be overcoming hardware compatibility, but the Debian community has grown so large it may be possible. Plus; they have been through it before, so they know what to expect. There are many kernels available aside from Linux. Some are even superior as far as code quality. The Linux kernel has gotten large and unmanageable. Does anyone really audit these millions of lines of code? We all hear everyone say "The code is open for anyone to look for exploits" but DOES ANYONE ACTUALLY DO IT? Or does everyone think someone else is going to do it, so they don't worry about? I strongly feel a new kernel would help preserve the Debian operating system, for it was such a huge success that many have copied it. -j
Re: Time for a new kernel?
IDEA: To tackle the driver issue & avoiding binary blobs, the project should focus on ONE hardware platform (until the project solidifies, then consider porting). Commodore 64 was immensely successful, and only had one set of hardware to support. Also, look at the success of the Raspberry Pi. Focus all effort into supporting one piece of hardware, then grow from there when possible. Preferably open-source hardware. (lemote anyone?) But focusing back on Linux kernel, their direction is questionable. Linus himself hates security. He doesn't care. That mentality will trickle down. On Mon, Nov 3, 2014 at 9:13 AM, Samuel Thibault wrote: > Jeremy, le Mon 03 Nov 2014 09:03:25 -0500, a écrit : > > if only the kernel were replaced, the rest would still work as we al > > like it to. (This is evident with Debian GNU Hurd & kFreeBSD projects). > > It's not so easy :) > > > We all hear everyone say "The code is open for anyone to look for > > exploits" but DOES ANYONE ACTUALLY DO IT? Or does everyone think > > someone else is going to do it, so they don't worry about? > > You'll end up with contradictory issues: having driver support and > having people look at the code. The non-driver parts of the kernel are > quite well looked at. Drivers, much less. Research has shown that > it's there that most bugs lie. And taking another kernel won't really > change that issue (if the other kernel is actually at all shipping other > drivers than just picking up Linux'). > > Samuel >
Swiftco.net mail verifier
THIS IS AN AUTOMATED EMAIL. The email you sent has displayed characteristics common to Spam messages. Because of this, your message has been flagged as potentially containing unsolicited email. The email you sent to jer...@swiftco.net requires Confirmation before it can be delivered. To do so, simply click reply and change the subject to this: [36329825998] Swiftco.net mail verifier Once this is done, you will never have to do this again. Remember, Put the Confirmation Code in the subject! [36329825998] -PORTION OF SENT MESSAGE FOLLOWS- > This message was undeliverable due to the following reason:> > Your message > was not delivered because the destination server was> not reachable within > the allowed queue period. The amount of time> a message is queued before it > is returned depends on local configura-> tion parameters.> > Most likely > there is a network problem that prevented delivery, but> it is also possible > that the computer is turned off, or does not> have a mail system running > right now.> > Your message was not delivered within 7 days:> Host > 199.94.203.124 is not responding.> > The following recipients could not > receive this message:> > > Please reply to > postmas...@lists.debian.org> if you feel this message to be in error. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110625072614.4e67613a7...@liszt.debian.org
Bug#1072679: ITP: papers -- PDF document viewer for GNOME
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:papers Owner: jeremy.bi...@canonical.com Package Name: papers Version: 46.1 Upstream Author: Pablo Correa Gómez, Markus Göllnitz, Evince authors License: GPL-2+ Programming Lang: C and Rust Description: PDF document viewer for GNOME Papers is a simple multi-page document viewer. It can display and print DjVu, Portable Document Format (PDF) and XML Paper Specification (XPS) files. When supported by the document, it also allows searching for text, copying text to the clipboard, hypertext navigation, and table-of-contents bookmarks. Other Info -- Papers is a fork of Evince. Papers uses GTK4 and libadwaita (evince uses GTK3). The app now uses Rust for some features. Papers has been proposed to replace Evince as the default PDF viewer for GNOME 47. Evince is not just an app but also libraries for other apps to support PDF (etc.) viewing. Papers also provides those libraries but they have been renamed and use GTK4 now. Those other apps may not be ready for GTK4 yet so we will keep the Evince libraries available for Debian 13. It hasn't yet been finalized what formats the app will support beyond PDF. DVI support has been dropped upstream. Debian, like most distros, has continued to enable viewing PostScript files in Evince although the Evince developers have disabled that by default for years. This package will be maintained by the Debian GNOME team. Packaging will be at https://salsa.debian.org/gnome-team/papers The upstream source is at https://gitlab.gnome.org/GNOME/Incubator/papers Thanks, Jeremy Bícha
Re: Mandatory LC_ALL=C.UTF-8 during package building
I believe debhelper already sets LC_ALL=C.UTF-8 for the cmake, meson, and ninja buildsystems; therefore many but definitely not all packages are already built with LC_ALL=C.UTF-8. Thank you, Jeremy Bícha
Bug#1072711: ITP: localsearch -- rename of tracker-miners
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:tracker-miners Owner: jeremy.bi...@canonical.com Package Name: localsearch Version: 3.8 (not yet released yet) Upstream Author: Sam Thursfield, Carlos Garnacho and others License: GPL-2+ (some parts are LGPL-2.1+) Programming Lang: C Description: metadata database, indexer and search tool - filesystem indexer This package contains the indexer for indexing your files and folders. . localsearch is an advanced framework for first class objects with associated metadata and tags. It provides a one stop solution for all metadata, tags, shared object databases, search tools and indexing. . localsearch was previously known as Tracker Miners. Other Info -- localsearch is a rename of the tracker-miners file indexer included by default in GNOME. The primary driver for this rename is that privacy-conscious curious users are disturbed by the persistent background process named tracker-miner-fs-3. It sounds like something is tracking users perhaps for malicious reasons. Miner brings to mind cryptocurrency miners that could have been installed without authorization. Concerned users can complain or may try to disable or remove these services and break core functionality of their desktop environment. The Debian GNOME team intends to package localsearch (and the tracker replacement named tinysparql) in Experimental probably in July. The intent is for the new binary packages to replace the existing tracker-miners packages. We expect to do the transition in Unstable later in the year. https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/346 Thanks, Jeremy Bícha
Bug#1072712: ITP: tinysparql -- rename of tracker
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:tracker Owner: jeremy.bi...@canonical.com Package Name: tinysparql Version: 3.8 (not yet released yet) Upstream Author: Sam Thursfield, Carlos Garnacho and others License: GPL-2+. Library: LGPL-2.1+ Programming Lang: C Description: metadata database, indexer and search tool TinySPARQL is an advanced framework for first class objects with associated metadata and tags. It provides a one stop solution for all metadata, tags, shared object databases, search tools and indexing. . TinySPARQL was previously known as Tracker. Other Info -- TinySPARL is a rename of the Tracker file indexer included by default in GNOME. The primary driver for this rename is that privacy-conscious curious users are disturbed by the persistent background process named tracker-miner-fs-3. It sounds like something is tracking users perhaps for malicious reasons. Miner brings to mind cryptocurrency miners that could have been installed without authorization. Concerned users can complain or may try to disable or remove these services and break core functionality of their desktop environment. The Debian GNOME team intends to package tinysparql (and the tracker-miners replacement named localsearch) in Experimental probably in July. The intent is for the new binary packages to replace the existing tracker packages. We expect to do the transition in Unstable later in the year. https://gitlab.gnome.org/GNOME/tracker/-/issues/437 Thanks, Jeremy Bícha
Re: DD's, Debian Mentors needs you!
On Sat, Jul 6, 2024 at 9:46 AM Phil Wyett wrote: > Debian Mentors[1] always struggles to find available Debian Developers for > final reviewing and > sponsoring of packages submitted too our part of the project. One thing that has disrupted my use of https://mentors.debian.net/ for sponsoring is that I am unable to log in. I don't get any of the "sign up" or "reset password" emails. Thank you, Jeremy Bícha
Bug#1075903: ITP: fonts-noto-emoji -- monochrome emoji font from Google
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,
pkg-fonts-de...@lists.alioth.debian.org
Control: affects -1 src:fonts-noto-emoji
Owner: jeremy.bi...@canonical.com
Package Name: fonts-noto-emoji
Version: 3.002
Upstream Author: Google
License: SIL-1.1
Programming Lang: N/A
Description: monochrome emoji font from Google
Noto is a collection of font families, each visually harmonized across
scripts.
.
The name "Noto" is short for "No Tofu", describing the aim of covering
all living Unicode scripts.
.
Tofu (豆腐) is Japanese jargon for unicode replacement character "�"
(U+FFFD) often displayed as replacement for unassigned or unknown
characters.
.
This package contains the monochrome ("black and white") emoji font.
Both an OpenType variable font and traditional static font files are
provided.
.
Please install fonts-noto-color-emoji instead if you want the color
font used on "stock" Android devices.
Other Info
--
Notably, Google has refused to provide the source for this font since
its introduction in 2022. This is disappointing since Google has been
a major contributor to open source fonts and tooling. Source code is
provided for other Noto fonts including the popular color emoji font
(packaged in Debian as fonts-noto-color-emoji).
There is a Github repo that is linked to in several places but the
repo is private: https://github.com/googlefonts/emoji-bw
Therefore, although this font is licensed under a compatible open
source license, I believe the font violates the Debian Free Software
Guidelines #2 which requires source code. Consequently, this package
will be uploaded to non-free. We hope that Google will eventually
release the source code and this package can be transferred to
Debian main.
This package will be maintained by the Debian Fonts Task Force.
Packaging will be at
https://salsa.debian.org/fonts-team/noto-emoji-font
The upstream homepage is at
https://fonts.google.com/noto/specimen/Noto+Emoji
References
--
https://github.com/googlefonts/noto-emoji/issues/390
https://www.debian.org/social_contract#guidelines
Thanks,
Jeremy Bícha
Bug#1076037: ITP: mozjs128 -- SpiderMonkey JavaScript library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org Control: affects -1 src:mozjs128 Owner: jeremy.bi...@canonical.com Package Name: mozjs128 Version: 128.0.0 Upstream Author: Mozilla etc License: mostly MPL-2.0, other files are licensed under other open source licenses Programming Lang: C++ Description: SpiderMonkey JavaScript library SpiderMonkey is the code-name for Mozilla Firefox's C++ implementation of JavaScript. It is intended to be embedded in other applications that provide host environments for JavaScript. . This library is intended for use in contexts where only trusted JavaScript code will be run, such as GNOME's gjs, Cinnamon's cjs, and polkit's rules parsing. It should not be used to run untrusted JavaScript from web pages: use a security-supported implementation such as Firefox, Chrome or WebKitGTK's JavaScriptCore instead. Other Info -- mozjs is the JavaScript engine from Firefox ESR. Today, a new Firefox ESR series was released. It will be supported by Mozilla for about 14 months. It is likely but not yet certain that GNOME 47, specifically gjs 1.82, will switch from mozjs115 to mozjs128. If that happens, the next major release of Debian (Debian 13 "Trixie") will include mozjs128. The other user of mozjs* in Debian is Cinnamon, specifically their cjs fork of gjs. Based on previous history, it is expected that cjs will continue to use mozjs115 for Debian 13. mozjs102 will be removed from Debian Unstable once cjs 6.2 reaches Unstable which is expected to happen "soon". References -- https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/936 https://whattrainisitnow.com/calendar/ Thanks, Jeremy Bícha
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote: [...] > To pick a random example, a less well known, less used, less > popular distribution like Nixos has 7000+ contributors listed on > Github. [...] Just to pick on this particular point, because I see this metric used all the time by projects trying to inflate public impressions of their size: you're aware that GitHub counts someone as a "contributor" even if all the do is leave a comment on a bug report, right? By that gauge, Debian is probably orders of magnitude larger. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On 2024-08-01 22:10:58 +0100 (+0100), Luca Boccassi wrote: > On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley wrote: > > > > On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote: > > [...] > > > To pick a random example, a less well known, less used, less > > > popular distribution like Nixos has 7000+ contributors listed on > > > Github. > > [...] > > > > Just to pick on this particular point, because I see this metric > > used all the time by projects trying to inflate public impressions > > of their size: you're aware that GitHub counts someone as a > > "contributor" even if all the do is leave a comment on a bug report, > > right? By that gauge, Debian is probably orders of magnitude larger. > > I'm not, no, I thought it was committers/authors? But I haven't really > looked it up so you might very well be right. Where did you find that > defined? Okay, it looks like I was conflating what GitHub counts as a "contribution" vs what kind of contribution makes someone a project "contributor." https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/managing-contribution-settings-on-your-profile/viewing-contributions-on-your-profile#what-counts-as-a-contribution> It was contribution counts I was remembering being inflated, not contributor counts. My apologies for the noise. -- Jeremy Stanley signature.asc Description: PGP signature
Re: make vcswatch detect "archived" status
On 2024-08-03 15:05:27 +0200 (+0200), Alexandre Detiste wrote: [...] > the vcswatch service could know about Gihub & Opendev infamous >"This project has been archived ..." [...] As one of the OpenDev Collaboratory sysadmins, I don't know how "infamous" that is on our end. There's no metadata for archived project status, just a convention that projects empty out their default Git branch and replace the readme with ad hoc information about ceasing maintenance or moving to another service. Also OpenDev currently only hosts a few thousand projects, nothing like the scale of GitHub, so I wouldn't recommend building large-scale workflows around our loose-knit community patterns. -- Jeremy Stanley signature.asc Description: PGP signature
Re: salt removed from mirror
On 2024-08-09 13:31:02 + (+), Johannes Drexl wrote: > I tried to install a system with Debian 11 and a preseed file today > from our internal mirror and found out that the package salt-minion was > gone. After some research (our mirror snapshots every day) I found out > that between 2024-06-29 02:00 and 2024-06-30 02:00 the whole salt > directory was silently dropped from the upstream mirrors. Even > packages.debian.org does no longer display any information about it. > > I was under the impression that the software stack of a > stable/oldstable release does not change anymore (safe for security > updates and suchlike), so I'm pretty flabberghasted by this. More so as > I cannot find a mention about this on debian-devel, where I would > assume such decisions would be discussed prior to the actual doing. > > Can somebody please shed some light on this? A quick bit of digging on https://tracker.debian.org/ indicates the salt-minion package was not part of Debian 11[*] since it retained at least one severe bug[**] which was never fixed. The change you observed seems to probably be related to cleanup of lingering debian-security content[***]. Hope that helps. [*] https://bugs.debian.org/1069654 [**] https://bugs.debian.org/1009804 [***] https://bugs.debian.org/1074468 -- Jeremy Stanley signature.asc Description: PGP signature
Re: Representing Debian Metadata in Git
On 2024-08-21 19:11:40 -0400 (-0400), rsbec...@nexbridge.com wrote: [...] > On the other side (perhaps), git is increasingly being used in the > Ops setting for DevOps and DevSecOps. Production configurations > for high-value applications are moving to storing those > configurations into git for tracing and audit. Git is an enabler > for good production operations practices. My $0.02 (and my > customers') This is nothing new though. Long before Git existed, before people started using terms like DevOps, it was fairly typical for sysadmins (that's what we called ourselves back then) to track the entirety of /etc in RCS. Yes having an auditable change history for your configuration is useful, but Git didn't invent that. Git has merely supplanted all prior version control systems, for this use case as well as others. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
On 2024-08-26 21:28:38 -0700 (-0700), Otto Kekäläinen wrote: > On Tue, 2 Apr 2024 at 17:19, Jeremy Stanley wrote: > > On 2024-04-02 16:44:54 -0700 (-0700), Russ Allbery wrote: > > [...] > > > I think a shallow clone of depth 1 is sufficient, although that's not > > > sufficient to get the correct version number from Git in all cases. > > [...] > > > > Some tools (python3-reno, for example) want to inspect the commits > > and historical tags on branches, in order to do things like > > assembling release notes documents. I don't know if any reno-using > > projects packaged in Debian get release notes included, but if they > > do then shallow clones would break that process. The python3-pbr > > You could use --depth=99 perhaps? > > Usually the difference of having depth=1 or 99 isn't that big unless > there was a recent large refactoring. Git repositories that are very > big (e.g. LibreOffice, MariaDB) have hundreds of thousands of commits, > and by doing a depth=99 clone you avoid 99.995% of the history, and in > projects where changelog/release notes is based on git commits, then > 99 commits is probably enough. [...] Maybe, but only if you want authorship, release note or changelog generation truncated at 99 commits worth of information at build time. Take OpenStack Nova for example, which has historically averaged around a thousand non-merge commits between major releases every 6 months; --depth=99 would be an order of magnitude too low to find just one major release's worth of notes and tags on a stable branch. Granted, this is why upstream in OpenStack we recommend package maintainers use our source distribution changelogs rather than rebuilding source themselves from code from version control. Our community considers our version control to be an implementation detail of our development workflow, not the primary means of supplying source code to downstream consumers. Where version control is concerned, we consider our source code to include the full Git metadata and not merely the files held in the worktree. For a hassle-free source distribution, we extract that metadata and incorporate the relevant parts as files in our signed source tarballs. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
On 2024-08-27 19:41:54 +0200 (+0200), tho...@goirand.fr wrote: [...] > All you wrote is precisely why I am not using these tarballs. I > know we don't agree... :) > > Also, the FTP master do NOT want the changeLog as they are too big > and provide no value when one can check the git repo to find the > same info. Sure, but the assembled release notes are not nearly as large as the changelog while still relying on having Git history available to build, and the generated authorship list is referred to in the license information for at least one OpenStack project as a stand-in for referencing Git committer metadata. To put it another way, upstream in OpenStack when the project was started in 2010, we were aware that package maintainers preferred signed and clearly versioned tarballs for every release, so that's what we structured our workflows and tooling around providing. In the meantime, package maintainers decided to take advantage of the fact that we use Git repositories in our development workflow but the release process we settled on isn't designed with that in mind, and changing workflows and processes in a developer community that size is sometimes like trying to steer a train. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Validating tarballs against git repositories
On 2024-08-28 00:21:27 +0200 (+0200), Thomas Goirand wrote: [...] > Well, I don't want to just package the generated stuff, I would > prefer to have the tools to generate them myself from source at > build time. And that's what has been bothering me since the > beginning: I do not know how to do that, currently, neither for > the authorship list or the release notes. In both case, the Git > repo is needed, and that doesn't fit at all a packaging workflow, > unless I embed all of the .git folder in the source package. This > was truth in 2010, and still is in 2024... > > As a consequence, I decided not to care, as I haven't find a > solution to "build from source", so I'm not packaging release > notes and authorship list. It's probably my fault that I didn't > contribute some fixes to reno though. For release notes, you can run `reno report` in a (non-shallow) Git checkout of any reno-using project and redirect its stdout to a file. Alternatively, PBR will call reno itself if it's found in the build environment when generating an sdist (this may require adding reno to the install_requires for the project when using build isolation). For example invoking `pyproject-build --sdist` will call SetupTools (PBR is a SetupTools plugin) to generate all of AUTHORS, ChangeLog, and RELEASENOTES.rst. Maybe pybuild from the dh-python package can do the same? But to bring the subthread back on topic, yes, all of this absolutely depends on having the Git branch history present, because the information required for all of these is the Git metadata itself. Storing another copy of the same data in flat files inside the worktree would be both duplicative and laggy, since some process would need to commit those files, and there lurks the specter of Gödel's First Incompleteness Theorem. Much in the same way Debian package maintainers have an aversion to reusing pre-generated files when they can be trivially recreated at package build time, some upstream projects have an aversion to checking generated files into version control if they can be recreated from existing contents of version control (not merely the versioned files but also the accompanying metadata). -- Jeremy Stanley signature.asc Description: PGP signature
Re: Intent to MBF: move from fuse to fuse3
On Thu, Aug 29, 2024 at 2:56 PM László Böszörményi (GCS) wrote: > On Sun, Aug 25, 2024 at 11:14 PM Chris Hofstaedtler wrote: > > Yeah, I agree. Do you want to upload a new src:fuse package dropping > > the fuse binary package? > > fuse3 already Provides: fuse, so that should be fine. > The question is, how many dependent packages use the binaries from > the fuse package or just depend on it. Sure, fuse3 provides fuse but > the names of the binaries are different. For example scripts need to > update fusermount call to fusermount3 call. As such, it might be > better to ping maintainers of those packages about dropping the fuse > binary for testing their packages first. Then after a month actually > drop it. On the other hand, I've read reports of people breaking their systems because they install fuse which uninstalls fuse3 (perhaps because they are trying to install libfuse2 to get AppImages to work or perhaps because fuse is a generic name). So I'd rather we got rid of the old fuse binary package quicker. https://launchpad.net/bugs/1978310 Although I guess it would be a lot of work to fix that for Debian 12. :( Thank you, Jeremy Bícha
Re: ITP: opencubicplayer -- Music file player
On Sat, 2005-03-26 at 12:53 +0100, GÃrkan SengÃn wrote: > Description : Music file player > This is a port of the Open Cubic Player to Linux. > . It would be nice if the description had some definition of what the software does. Video player? Audio player? Without any previous exposure to the "Open Cubic Player", I can only assume that it plays... well... cubes. :) signature.asc Description: This is a digitally signed message part
Re: GPL and linking
Humberto Massa <[EMAIL PROTECTED]> writes: > ??? Let's try again: All of this discussion of legal minutia misses (and perhaps supports) what, to my mind, is the most compelling argument for accepting the FSF's position on the subject. The fact is that the question does depend on a lot of legal minutia that almost all of us aren't qualified to have an opinion on. So unless it's a make-or-break issue for Debian (which I just don't see), the obvious thing to do is to take the agreeable, safe position. So the question of whether or not the FSF is actually *right* doesn't matter. We should only disagree with them if we have to for the sake of Debian -- in which case we're probably in trouble and should hire a lawyer ASAP. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking
"Michael K. Edwards" <[EMAIL PROTECTED]> writes: > You may not be qualified (as I am not) to offer legal advice. But > you're certainly qualified to have an opinion. Sure. But it's not relevant to this discussion -- despite what many of the participants seem to believe. > And there isn't > necessarily an "agreeable, safe position". Are you saying there's not? So who's going to sue me (or Debian) for adopting an overbroad idea of what constitutes a derivative? "Hey, you decided to abide by my license terms when you didn't have to. I'm gonna sue!" (Standing? What's that?) Conversely, if our idea of what constitutes a derived work is too narrow we could end up violating someone's copyright. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
sarge upgrade issue. perl 5.6->5.8 and libdb4
I just ran through a woody-sarge update, and (temporarilly) lost a number of perl databases that an unpackaged app had created. Took me quite a while to figure out exactly what happened, more time than a user should normally be expected to put into debugging I think. Woody's perl 5.6 uses libdb2. Sarge's uses libdb4. libdb4 cannot natively open databases created with libdb2, and while this point is stated in perl's changelog, I don't believe most users will read all 20 pages of changelog entries that have occured since then, and there appeared to be no notification in the process of the upgrade that such an issue would take place. There is an upgrade script available, but afaict it's only reference is buried deep in that changelog. Sounds like a perfect place to use a NEWS.gz file and apt-listchanges, if there's a way to enforce the installation of apt-listchanges. Comments? signature.asc Description: This is a digitally signed message part
Re: sarge upgrade issue. perl 5.6->5.8 and libdb4
On mer, 2005-05-25 at 21:52 +0200, Javier Fernández-Sanguino Peña wrote: > Maybe it's best if you provided a patch to the Release Notes, we might need > to draft a section on "known upgrade issues" (was there in previous > versions of the RN) and add that info (and other similar stuff) there. I should probabbly point out that I am not a debian developer, nor do I really have any clue where to go with this. Just wanted to make sure somebody more involved in the process than me was involved in the process. signature.asc Description: This is a digitally signed message part
Re: Request for virtual package ircd
On Thu, Oct 12, 2006 at 09:14:19AM +0200, Mario Iseli wrote:
> Ok, this is a good argument.
> I think the oppinion is more or less clear:
>
> Some people think it would be a nice idea, BUT it can be also a problem
> because some people want more than one Ircd on a system.
>
> I only wanted to ask you for your oppinion, so thank you all! :-)
Maybe what you're looking for is a "Provides: irc-server" in the
ircd packages and a "Recommends: irc-server" or "Suggests:
irc-server" in the service packages that potentially benefit from
(but do not necessarily require) a locally-installed ircd to which
to connect? That way when someone installs the services via, say,
aptitude or synaptic, an ircd is pulled in automatically (if one is
not already installed) or at least mentioned as being suggested, but
multiple ircd packages providing irc-server could still be installed
on the same system since there is no conflict expressed.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release Date Update
On Mon, Mar 20, 2006 at 05:39:23PM -0600, Ron Johnson wrote:
> On Mon, 2006-03-20 at 23:15 +, Colin Watson wrote:
> > On Mon, Mar 20, 2006 at 02:51:25PM -0800, Mark Shuttleworh wrote:
> >
> > (In case it wasn't clear, this wasn't Mark Shuttlewor*t*h posting.
> > Please don't feed the troll.)
>
> Even so, are his points valid?
Questionable... For starters, there is no global Summer, so what
hemisphere would Debian choose to favor? Seems a little silly to me.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Maintainers Guide (was: How (not) to write copyright files - take two)
On Sun, Mar 26, 2006 at 08:48:31PM +0200, Nico Golde wrote:
> * Joerg Jaspert <[EMAIL PROTECTED]> [2006-03-26 20:31]:
> > A while ago Peter 'weasel' Palfrader wrote a nice little "How (not) to
> > write copyright files"[1]. Please read that *now*.
> >
> > [1] http://lists.debian.org/debian-devel-announce/2003/12/msg7.html
>
> [...]
> Why not add this to the New Maintainers Guide instead of
> forcing Applicants to search the mailing list archive for
> this?
Furthermore, the format given in the message is dissimilar from what
dh_make (0.40) gives right now. The default is...
This package was debianized by Jeremy Stanley <[EMAIL PROTECTED]> on
Sun, 26 Mar 2006 19:12:01 +.
It was downloaded from
Copyright Holder:
License:
...with no dates of copyright and no implication (in the template)
that they should be included either (related to "resolved" bug
336982). If the bulk of new maintainers are creating their packages
based on dh_make's templates, I expect many copyright files will
lack years (well, one would hope their sponsors would catch this). I
would happily submit a (trivial) patch for it, except that this
appears to be intentional for reasons I'm currently unable to
fathom. The original submitter indicates (among other things):
This has to include a copyright year, also.
...and following additional discussion, the resolution is:
After considering the suggestion, I have decided to close this
bug.
Section 4.2 of maint-guide (1.2.7) shows the slightly different
"Copyright:" in place of "License:" and gives an example including
"the complete copyright notice," so hopefully more clueful
first-time packagers won't be bitten by the vagueness in the
template.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364317: ITP: weather-util -- command-line tool to obtain weather conditions and forecasts
On Sat, Apr 22, 2006 at 08:02:20PM +0200, gregor herrmann wrote:
> You might (with your upstream hat on) take a look at (python-)pymetar,
> a nice python module that can retrieve METAR data from all around the
> world.
Thanks! I actually looked at it before I started writing my util,
and it looks like a great module for doing flexible things with
METARs. All I needed was a way to display decoded equivalents in a
user-friendly format, which NOAA already provides, and needed to
retrieve the forecast data anyway. It seemed logical to just use a
consistent interface to deal with both, but if I were trying to do
something significantly more complicated, I would of course
integrate pymetar (or a similar module if others exist).
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Non-DD's in debian-legal
Disclaimer: I am not a DD, nor in the n-m queue. I'm also
re-crossposting to debian-devel, because I don't think this discussion
could usefully be had on debian-legal -- and it's not a licensing issue
anyway.
Anthony Towns writes:
> I don't believe that saying someone isn't a developer is contemptuous.
> It's very easy to fall under the misapprehension that the views of
> some participants on debian-legal represent the views of the Debian
> project as a whole,
This statement could, of course, be generalized to refer to any mailing
list and any group of participants, and it would still be just as true.
If this is a particular problem for d-l it's because people often ask
d-l for a definitive judgement on a license, and the list is simply not
set up to deliver on that request. There have been a few attempts
(summaries, for example), but they never worked well.
> however, and particularly when that applies to
> individuals who aren't members of the Debian project, that does a
> serious disservice to people who are.
I'm not sure I understand this part, though. Do you think that folks
like myself, who are not DD's, should not participate in the discussions
on d-l? Do you think that those of us who are not DD's should put a
disclaimer (IANADD) on every message to the list? I can tell you from
experience that the latter gets pretty distracting after a while. This
is a serious question, btw, because you're pointing to what you
evidently consider to be a serious problem, yet you're not suggesting a
solution.
For whatever reason, this issue seems to be a particular problem for
d-l. Every so often someone claims that the results of discussions on
d-l aren't valid because d-l is populated by a bunch of non-DD's, or
tries to discount someone's argument because that person isn't a DD.
Mostly I write that off as sour grapes over being on the losing side of
an argument. But when it comes from a duly elected official in the
Debian organization, I have to take a step back and wonder what the
problem is.
My opinion, for what it's worth, is that most DD's, despite occasionally
having strong opinions on licensing ("*This* license is _free_, @#$^!")
are totally uninterested in taking the time to sort through the
nitpicking arguments about language, jurisdiction, and law, etc., that
are needed to make a decision on a particular license or work. That
leaves a vacuum on d-l, where such discussions are supposed to take
place.
So that leaves those of us who may not be DD's but (by whatever
perversion of character) are actually interested in discussing licenses,
and motivated to ensure that the quality of the licensing of Debian
software remains as high as that of the software itself. We, naturally
enough, have helped to fill that vacuum. Unfortunately, licensing
issues tend toward flame wars because, as I mentioned before, people
tend to have strong opinions without wanting to take the time to ground
those opinions in the facts. These flame-fests lead some people to try
to find reasons to discount their opponents, and on d-l that reason is
often simply that some of the participants are not DD's.
So I don't think this problem is going away, nor do I think it's a
serious one. After all, if DD's really think licensing issues should be
discussed behind closed doors, they're free to pass a GR taking
debian-legal private. But if you have a different opinion on the issue,
I'd like to hear it.
(Note that I am not at all talking about the whole Sun java bit. I
personally find it hard to get worked up about non-free software going
into non-free. Perhaps legal counsel should have been sought, but
that's not my call.)
--
Jeremy Hankins <[EMAIL PROTECTED]>
PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
Matthew Garrett <[EMAIL PROTECTED]> writes: > Starting with "What is key for Debian" makes it sound like a policy > statement on behalf of Debian, and "Just fix the license" could then > be interpreted as a demand from Debian that Sun alter the license. In > that context, it seems reasonable to point out that Walter is not in a > position to speak on behalf of Debian. That's entirely reasonable. Perhaps I misinterpreted aj's message somewhat. It seemed to me to be placing rather more emphasis on Walter not being a DD. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
Adeodato Simó <[EMAIL PROTECTED]> writes: > So let's make an analogy. Imagine one day, the bulk of Debian Developers > stop being interested in maintaining GNOME (or KDE, if you wish). The > packages begin to rot, become obsolete, uninstallable, etc. Then, a group > of non-developers who care about GNOME and, also, care about GNOME being > in good shape in Debian, step up and try to help. Absolutely. That's the Debian Way(tm). > The thing is that, no matter how much they work and no matter how high > quality their packages are, at the end it _HAS_ to be a Debian Developer > the one to sign the .changes file. Credit and acknowledgement will go > to the non-developers, of course, since they did the work, but a DD has > to review and sign it before it is consider oficially part of Debian. That's where the analogy breaks down, though. Analyzing software licensing situations doesn't require upload rights or a key on the developer key-ring. In fact, it doesn't require any developer privileges at all -- unless you count posting on debian mailing lists and occasionally filing bugs as developer privilege. > And, if sadly no developer would be interested in uploading those packages, > those contributors do not get to create an Alioth project, set up a > repository, _and_ tell the world those are the official GNOME packages for > Debian. They can create the project, set up the repo, and inform interested > parties that they believe those packages are suitable for Debian, that they > would like to see them in the official archive, and the reasons why they are > in gnome.alioth.debian.org instead of ftp.debian.org. > > As you'll understand, nobody would like for debian-legal@lists.debian.org > to become the gnome.alioth.debian.org in the example above. I'm afraid I don't understand the fear here. What would it mean for d-l to become gnome.alioth.debian.org in your example? -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Non-DD's in debian-legal
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Well, no, that's not actually true. Debian developers get a say in > whatever they're responsible for. Whether that whatever is a bunch of > packages on which they're listed as Maintainer, or a port they've been > maintaining for a few years, or a programming language for which they > maintain an extraordinary amount of packages and have been helping out > in shaping a policy for, or some appointed position (as in this case) > really isn't all that important. That is a crucial difference between d-l and many other responsibilities in Debian: ultimately, d-l is only advisory. > If somebody not involved with the m68k port comes and tells me that > some decision I made for m68k is all wrong and that I should've done > this or that instead, I'll have a good laugh. And go on with doing > whatever I was doing. > > Which, I think, is what the ftp-masters should do to this thread. That's probably good advice for those of us who contribute to d-l, too. Except for one thing: if there's significant distrust or antipathy directed toward d-l it interferes with our ability to give advice on software freedom issues because people don't listen to us. That, ultimately, is why I posted my original message. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DD's in debian-legal
Ian Jackson <[EMAIL PROTECTED]> writes:
> Jeremy Hankins writes ("Non-DD's in debian-legal"):
>> I'm not sure I understand this part, though. Do you think that folks
>> like myself, who are not DD's, should not participate in the discussions
>> on d-l?
>
> Actually, I think they should not participate, in general.
I've given this a fair amount of thought. You make some good points,
and some of them strike quite close to home for myself, so I clearly
have to give them some weight. But I don't think you've got the whole
picture here.
> The arguments that are had on debian-legal about what is an acceptable
> licence, and what principles these decisions should be based on, are
> often very political. Political decisions in Debian should be taken
> by DD's.
This is the point that bothers me the most. It's certainly true that
licensing decisions are in part political. But it's also the case that
they are in part technical. Not in the sense of having to do with
technology and computers, but in the sense of hinging upon particular
details and specialized knowledge. It is quite possible to get a
licensing issue empirically wrong, after all.
This came up with the recent GR on the GFDL. There was a bit of
discussion on d-l about how to interpret it: was it amending the DFSG,
or specifying an interpretation for the GFDL? If it was the first,
exactly what was the amendment, and why didn't it say it was amending
anything? If it was the latter wasn't it a bit like legislating pi or
outlawing the tides: an attempt to fix by legislative fiat something
which we have no control over in the first place. In the end I think
this was (sort of) resolved by interpreting the GFDL GR as specifying an
interpretation, but only for the purposes of the DFSG. (Of course, as a
political issue being discussed on d-l, this proves your point.)
I'm not trying to re-raise the whole GFDL debate. But I do think it was
an example of where Debian could go wrong by treating licensing issues
as political issues. In the end, there's a real world out there with
real judges and real courts, and we can't act as if they don't exist.
It's certainly true that licensing issues are intensely political. And
it's probably impossible to disentangle the politics from the technical
(factual) issues. And Debian, as an organization, has a right to say
that internal politics are internal, and not something for outsiders
like myself to be party to. If that's the case, though, political lists
should really be taken private, or posting limited to members, or
whatever.
Personally, I think that one of Debian's strengths is its openness, and
willingness to have discussions in front of and with outsiders. Though
naturally, I say that as an outsider.
> Arguments about licences are phrased as if the questions are all
> clear-cut and right-or-wrong, but actually usually they're matters of
> interpretation where weight of numbers on one side or another ends up
> often carrying the day. (`Am I really the only person who thinks this
> is completely mad?' `No, but all the rest of them are too busy writing
> software.')
If they're busy writing software they're probably not up to speed on the
technical/factual issues. So it's a fair question to ask whether their
opinion is relevant. In the end that's a variation of "the lurkers
support me."
This is one of the most common accusations leveled against d-l: that the
membership of d-l is skewed and not representative of Debian as a whole.
If that's true there's not much d-l can do about it, of course, and the
whole process of license evaluation should perhaps be rethought. The
simplest solution, though, is for those who think d-l skewed to start
participating.
> The situation with non-DD's pontificating about what is and is not an
> acceptable Free licence is mitigated somewhat by the fact that
> debian-legal is only a talking shop and doesn't actually decide, but
> as we've just seen, people (both people from debian-legal and
> elsewhere) do seem to think that debian-legal is or ought to be where
> these decisions are taken.
I think what's concerning to most (it concerns me) is that people seem
to be _avoiding_ d-l, presumably because they see it as invalid or
corrupted by weirdos. That's indicative of a serious problem, because
it means licensing issues aren't being discussed _at all_. As saddened
as I would be if d-l went private, if doing so is the only way to solve
that problem it's probably a good idea.
> Discussions about licensing are different from most other kinds of
> activity in Debian precisely because they're political and have a very
> low barrier to entry. Picking up the slack in licence appr
Re: make -j in Debian packages
On Fri, Jun 30, 2006 at 12:12:10PM +0200, Adam Borowski wrote:
> Oh, so you mean checking the _free_ RAM instead of the _physical_ RAM?
> This would be reasonable -- I didn't use this in the debian/rules
> snippet I proposed as the physical memory is a trivially discernable
> number while free RAM can be sometimes hard to tell, especially on Xen:
[...]
> Of course, when I say that something is tricky, it doesn't mean that
> someone with more clue than me can't do it.
[...]
Just grep it out of /proc/meminfo? Something like this ugly bit of
bourne shell:
echo $(
grep ^MemTotal: /proc/meminfo | awk '{ print $2 }'
) - $(
grep ^MemFree: /proc/meminfo | awk '{ print $2 }'
) - $(
grep ^Buffers: /proc/meminfo | awk '{ print $2 }'
) - $(
grep ^Cached: /proc/meminfo | awk '{ print $2 }'
) | bc
Which would give you a count of the total kb minus what's free and
in use for buffers/cache, similar to what free(1) spits out, but
probably not identical. That might not be an option on older kernels
(I seem to remember dealing with some /proc/meminfo change a while
back that broke check_swap in nagios-plugins), or at least might
differ at particular points in the kernel's release history.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New Naming Convention
Title: New Naming Convention I currently do not subscribe to the mailing lists. So I don't know if this has been considered. I want to offer a suggestion for a new distro naming convention. I have enjoyed the Toy Story names. But perhaps it has run it's course. We have used 10 toy stoy names over a period of 10 years. That is a good round number and would be a logical place to start anew. If Debain were to name the new testing branch "Andy" (the owner of all the toys). That would make a good ending point and when it is moved to stable, a new naming convention could be instituted for the testing and unstable branches. I propose that Debian continue along the same vein with characters from a different Pixar movie. IMO, Finding Nemo makes a lot of sense. It has a lot of named characters that will provide years of distro names. The unstable branch could be forgetful "dory" or undiciplined "darla". That is just a simple suggestion that I wanted to submit. Thank you for taking the time to read this and pass it along for consideration. Jeremy
Re: intent to hijack python-paramiko
Go ahead and NMU with my thanks and blessing... I've made my move cross-country but my system at home is still without network connectivity at this time and the telco has been unable to give me anything close to a firm ETA of when they will. Regards,JeremyOn 7/17/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote: * Wouter van Heyst <[EMAIL PROTECTED]> [2006-07-17 20:35]:> > He was moving cross-country in May, so I suggest you NMU for now.>> Would NMUing a new upstream be ok in this instance then? I think so, yes.--Martin Michlmayrhttp://www.cyrius.com/
Re: Should this be filed as grave? Gcc-2.95
Matt Zimmerman <[EMAIL PROTECTED]> writes: > A more useful question would be, why does gcc-2.95 depend on gcc? The > answer, as usual, you could have found for yourself in the changelog: > > gcc-2.95 (2.95.3.ds3-5) testing unstable; urgency=low > > * For each binary compiler package xxx-2.95 add a dependency on > xxx (>= 1:2.95.3-2). Fixes #85135, #85141, #85154, #85222, #85539, > #85570, #85578. > * Fix typos. Add note about gcc-2.97 to README (fixes #85180). > > -- Matthias Klose <[EMAIL PROTECTED]> Mon, 12 Feb 2001 01:19:59 +0100 > > You may refer to all of those bugs for reasons why this is so. I'd love it if someone could explain the problem in a bit more detail for me. I was bitten by this kernel/gcc issue myself, and having looked at those bug reports I'm still not clear what was happening, other than that gcc-2.95 was somehow breaking g++/libstdc++ in testing. Just curious. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Bug#543898: ITP: rabbitmq-stomp -- A STOMP gateway for RabbitMQ
Package: wnpp Severity: wishlist Owner: Jeremy Lal * Package name: rabbitmq-stomp Version : 1.6.0 Upstream Author : Tony Garnock-Jones * URL : https://dev.rabbitmq.com/wiki/StompGateway * License : MPL 1.1 Programming Lang: Erlang Description : A STOMP (Simple Text-Oriented Messaging Protocol) gateway for RabbitMQ Best of both worlds : STOMP for its simplicity, rabbitmq-server for reliability. This plugin is not yet ready for production use, though it seems quite stable. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543964: ITP: python-orbited -- HTTP daemon that is optimized for long-lasting comet connections
Package: wnpp Severity: wishlist Owner: Jeremy Lal * Package name: python-orbited Version : 0.7.10 Upstream Author : Michael Carter * URL : http://www.orbited.org/ * License : MIT Programming Lang: Python Description : HTTP daemon that is optimized for long-lasting comet connections It provides a pure JavaScript/HTML socket in the browser. It is a web router and firewall that allows you to integrate web applications with arbitrary back-end systems. You can implement any network protocol in the browser—without resorting to plugins. The client-side files are separately packaged in libjs-orbited. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543968: ITP: libjs-orbited -- TCPSocket javascript client for networking with orbited
Package: wnpp Severity: wishlist Owner: Jeremy Lal * Package name: libjs-orbited Version : 0.7.10 Upstream Author : Michael Carter * URL : http://www.orbited.org/ * License : MIT Programming Lang: Javascript Description : TCPSocket javascript client for networking with orbited Orbited is a central part for providing support of the new WebSocket HTML5 object, which is the standard proposed for COMET client applications. Support for other protocols (STOMP, IRC, XMPP, TELNET) is also included. This package is a recommendation of package python-orbited. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550244: ITP: redmine-plugin-botsfilter -- Redmine plugin to restrict common bots
Package: wnpp Severity: wishlist Owner: Jeremy Lal * Package name: redmine-plugin-botsfilter Version : 1.01 Upstream Author : Jean-Philippe Lang * URL : http://www.redmine.org/wiki/redmine/PluginBotsFilter * License : GPL-2 Programming Lang: Ruby Description : Redmine plugin to restrict common bots Prevent common bots from accessing: * alternate format download links (eg. csv, pdf) * gantt, calander * repository * wiki history -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553514: ITP: node.js -- Event-based I/O for V8 javascript
Package: wnpp Severity: wishlist Owner: Jeremy Lal * Package name: node.js Version : 0.1.15 Upstream Author : Ryan Dahl * URL : http://nodejs.org * License : MIT Programming Lang: C++, Javascript Description : Event-based I/O for V8 javascript Node aims at providing a basis for server-side javascript. . It is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. . Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#411833: ITP: gozerbot -- An IRC and Jabber bot written in Python
Package: wnpp Severity: wishlist Owner: Jeremy Malcolm <[EMAIL PROTECTED]> * Package name: gozerbot Version : 0.6.1 Upstream Author : Bas van Oostveen <[EMAIL PROTECTED]> * URL : http://r8.cg.nu/ * License : BSD Programming Lang: Python Description : An IRC and Jabber bot written in Python This is a bot which can simultaneously inhabit one or more IRC channels and Jabber services, providing facilities such as: . - Fetching RSS feeds - Keeping to-do and shopping lists - Relaying between bot instances - Anything else you develop a plugin to do -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.26-3um Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#507261: ITP: trac-authopenid -- OpenID authentication plugin for Trac
Package: wnpp Severity: wishlist Owner: Jeremy Laine <[EMAIL PROTECTED]> * Package name: trac-authopenid Version : 0.1.6 Upstream Author : Dalius Dobravolskas <[EMAIL PROTECTED]> * URL : http://trac.sandbox.lt/auth/wiki/AuthOpenIdPlugin * License : Trac license (modified BSD) Programming Lang: Python Description : OpenID authentication plugin for Trac This plugin make it possible to login to Trac using the OpenID decentralized identity system. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enabling and installing of "risky" ("patented") codecs - made easy
On Tue, Oct 23, 2007 at 09:15:42AM +0200, Fabian Greffrath wrote:
[...]
> I suggest that, if such a repository will be created for patented
> codecs, that e.g. sponsored uploads will not be allowed to this
> archive. I know that most of you will hate this idea, but I
> believe it is necessary to keep the original purpose of such an
> archive.
As a sponsoree myself, I'm not entirely certain I understand why
it's any more likely that a sponsoring DD will overlook and upload a
package with the wrong section, than that a DD will upload a
similarly incorrect package he or she directly maintains. And either
way, wouldn't verifying that a package is appropriate for some new
patent-problems section fall on the ftpmasters and their delegates
to police? And further, if this became canonized in policy as a must
or required directive, wouldn't such a problem warrant a bug of
severity serious, potentially release-critical even?
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#195481: Join our marketing team
We are Looking for partners worldwide. The position is home-based. Our Company Head Office is located in UK with branches all over the world. We are looking for talented, honest, reliable representatives from different regions. The ideal candidate will be an intelligent person, someone who can work autonomously with a high degree of enthusiasm. Our Company offers a very competitive salary to the successful candidate, along with an unrivalled career progression opportunity. If you would like to work with our active, dynamic team, we invite you to apply for employment. Preference will be given to applicants with knowledge of multiple languages. Please send the following information to [EMAIL PROTECTED] 1. Full name 2 Address of residence 3 Contact Phone numbers 4 Languages spoken 5 Whether you are interested in part time job or full time employment. Thank you. We look forward to working with you. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#574967: ITP: multiwatch -- Forks and watches multiple instances of a program
Package: wnpp Severity: wishlist Owner: Jeremy Lal Owner: Jeremy Lal * Package name: multiwatch Version : no upstream version (yet) Upstream Author : Stefan Bühler * URL : http://cgit.lighttpd.net/multiwatch/ * License : MIT Programming Lang: C Description : Forks and watches multiple instances of a program multiwatch forks multiple instance of one application and keeps them running; it is made to be used with spawn-fcgi so all forks share the same fastcgi socket (no webserver restart needed if you increase/decrease the number of forks), and it is easier than to setup multiple daemontool or runit supervised instances. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100322142234.8516.43207.report...@localhost.localdomain
Bug#584570: ITP: portabase -- An easy-to-use personal database application
Package: wnpp Severity: wishlist Owner: Jeremy Bowman * Package name: portabase Version : 2.0 Upstream Author : Jeremy Bowman * URL : http://portabase.sourceforge.net/ * License : GPL Programming Lang: C++ Description : An easy-to-use personal database application PortaBase is a program for conveniently managing one-table database files. It is available for many platforms, including Linux, Mac OS X, Windows, and Maemo. Features include: * String, Integer, Decimal, Boolean, Note (multi-line text), Date, Time, Calculation, Sequence, Image, and Enum column types; * custom data views (subsets of the columns in any order); * filter the displayed rows using sets of conditions; * sort the rows by any combination of columns, each in ascending or descending order; * add, delete, rearrange, and rename columns at any time; * view summary statistics for columns (total, average, min, max, etc.); * import data from CSV, XML, and MobileDB files; * export data to CSV and XML files; * command-line format conversions (to and from XML, from MobileDB); * optional data file encryption. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100604084634.3090.60696.report...@debianvm.comcast.net
Bug#589393: ITP: npm -- package manager for nodejs
Package: wnpp Severity: wishlist Owner: Jeremy Lal * Package name: npm Version : 0.1.19 Upstream Author : Isaac Zimmitti Schlueter * URL : http://github.com/isaacs/npm * License : MIT Programming Lang: Javascript Description : package manager for nodejs npm provides management of nodejs JavaScript libraries and applications: it allows to publish, tag, and install and handle dependencies of nodejs modules using common.js packaging spec. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100717101923.30842.44832.report...@localhost.localdomain
Bug#589470: ITP: eot-utils -- Converter from OpenType or TrueType to Embedded OpenType (EOT) font format
Package: wnpp Severity: wishlist Owner: Jeremy Lal * Package name: eot-utils Version : 1.0 Upstream Author : Bert Bos * URL : http://www.w3.org/Tools/eot-utils/ * License : W3C SOFTWARE NOTICE AND LICENSE Programming Lang: C Description : Tools to convert from OTF or TTF to EOT font format The eot-utils are the two programs mkeot and eotinfo. The former creates an EOT (Embedded OpenType) file from an OpenType or TrueType font and the URLs of one or more Web pages. mkeot respects the TrueType embedding bits. The eotinfo program displays the contents of an EOT header in a human-readable way. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100717234222.4574.68063.report...@localhost.localdomain
Bug#592413: ITP: qxmpp -- cross-platform C++ XMPP library
Package: wnpp Severity: wishlist Owner: Jeremy Lainé * Package name: qxmpp Upstream Author : Manjeet Dahiya * URL : http://code.google.com/p/qxmpp/ * License : LGPL Programming Lang: C++ Description : cross-platform C++ XMPP library QXmpp is a cross-platform C++ XMPP library built upon Qt. It strives to be as intuitive and easy to use as possible. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100809205725.23142.16198.report...@sharky
Bug#600981: ITP: lv2file -- A command-line program to apply LV2 effects to files
Package: wnpp Severity: wishlist Owner: Jeremy Salwen Package name: lv2file * Version : 0.6 Upstream Author : Jeremy Salwen * URL : http://code.google.com/p/lv2file/ * License : GPL 3 Programming Lang: C Description : A command-line program to apply LV2 effects to files lv2file is a simple program which you can use to apply LV2 effects to your audio files without much hassle. Possible use cases of lv2file are: * You want to apply an effect without having to open a GUI or start a project. * You want to apply effects to a large number of files, or in an automated manner. * You need a deterministic environment to debug a plugin you are developing. * You want your audio tools to be command line only. lv2file does not come with any built-in effects, so you must install other packages containing LV2 plugins to use with lv2file. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101022044227.4847.4971.report...@localhost.localdomain
Bug#607957: ITP: jsonbot -- Framework for building bots for IRC, XMPP and the Web
Package: wnpp Severity: wishlist Owner: Jeremy Malcolm * Package name: jsonbot Version : 0.5.4 Upstream Author : Bart Thate * URL : http://code.google.com/p/jsonbot/ * License : MIT Programming Lang: Python Description : Framework for building bots for IRC, XMPP and the Web JSONBOT is a remote event-driven framework for building bots that talk JSON to each other over XMPP. This distribution provides bots built on the JSONBOT framework for console, IRC, XMPP for the shell and WWW, and XMPP for the Google App Engine. A plugin infrastructure can be used to write your own functionality. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101225022345.24347.24969.report...@tardis.malcolm.id.au
Bug#608848: ITP: so-synth-lv2 -- A set of synthesizers for the LV2 plugin format
Package: wnpp Severity: wishlist Owner: Jeremy Salwen * Package name: so-synth-lv2 Version : 1 Upstream Author : Jeremy Salwen * URL : https://github.com/jeremysalwen/SO-synth-LV2 * License : GPL Programming Lang: C Description : A set of synthesizers for the LV2 plugin format This package is an unofficial port of the SO-666 synthesizer to the LV2 plugin format. In order to use it, you need a host for LV2 plugins such as Ardour, Qtractor, or Ingen. This package contains three synthesizers, a feedback drone synthesizer, a piano synthesizer, and a bassline synthesizer. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104001044.29424.33663.report...@hub2.verizon.net
Re: discover or alsa?
On mer, 2004-10-13 at 10:30 +0200, Thomas Hood wrote: > Lots of users are reporting that ALSA sound doesn't "just" work when > they install it. The cause of the problem is the fact that discover > loads OSS modules even when ALSA modules are available. This bug cannot > be worked around consistently with policy because discover offers no > mechanism for blacklisting modules other than editing a conffile. The > bug report against discover1 (#220616) has been tagged "wontfix" so I am > not expecting the discover maintainers to solve the problem. > > Given these facts, what should the ALSA packaging team do? It seems > that the alsa packages should Conflict with discover and discover1. > -- > Thomas Hood For what it's worth, hotplug recently had a similar issue on a test install for me: it actually loaded both OSS and ALSA drivers for my soundcard. signature.asc Description: This is a digitally signed message part
Re: Bug#158631: ITP: mp32ogg -- Converts mp3 file to Ogg Vorbis
In particular, it's important to note that transcoded MP3's, even _legally_ transcoded MP3's, should never ever ever be distributed, lest people associate the degradation in quality (even if it's something most people can't hear) with a problem in vorbis. On Wed, 2002-08-28 at 13:32, Julien Danjou wrote: > Le Wed, Aug 28, 2002 at 09:18:41PM +0200, Paul Dwerryhouse a écrit: > > > > On Wed, Aug 28, 2002 at 02:29:22PM -0300, Ben Armstrong wrote: > > > I'm staying neutral on the quality issue. Yes, degrading mp3s into oggs > > > sucks. Yes users should have a choice. I don't know which is more > > > important > > > in this case. > > > > Put it in and whack a f*cking huge warning message everytime the program > > is run ... something like "YMMV", but a little more educational. > > I will put a note in README.Debian. > > > For what it's worth, I've converted a good number of 128kB/s mp3s to ogg > > today for personal testing purposes (my original CDs, from which they were > > ripped, are in another country) and they sound fine to me. I suspect > > a good number of other people would be happy enough with such a > > situation, so why not make it easy for them? > > I agree with you. I have converted most of my MP3 in ogg, and the sound > is not so bad for me. > > -- > Julien Danjou > > .''`. Debian developer > : :' : http://jdanjou.org > `. `' http://people.debian.org/~acid > `- GPG: 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Jeremy Nickurak -= [EMAIL PROTECTED] =-
Re: /run and read-only /etc
Can someone point me the message(s) discussing /run (and why not
/etc/run) - I would like to think that adding another directory off /
should be avoided. /etc/run sounds nice, unless you want to support
booting before /etc is mounted...
Cheers,
Jeremy
On Wed, 2003-04-09 at 14:17, Thomas Hood wrote:
> Here are:
> * an updated list of wishes,
> * an updated TODO suggestion for resolv.conf based on Emile's idea,
> * a brief rationale for adding /run/,
> * and a discussion of some FHS passages that present problems.
>
> We need to find more of the programs that routinely write to /etc.
> Russell might be of some help here. :)
>
> The read-only root effort
> =
>
> Wish reports filed or updated
> * sysvinit
> #150355: Please move motd to /var/lib/
> NEW: #188087: Move ioctl.save out of /etc/
> * util-linux
> #156489: Please move adjtime out of /etc/
> * ppp
> #187756: Patch to allow /etc/ to be read-only
> * pppconfig
> #187810: Please support read-only /etc/
> /etc/ppp/ip-up.d/0dns-up and /etc/ppp/ip-down.d/0dns-down
> shouldn't create temporary files in /etc/
> #187651: Please document how to keep resolv.conf static
> * linuxlogo
> #187953: Please do not store files in /etc/. Use /var/lib/.
> * cupsys
> #187954: Move /etc/printcap.cups under /var/
>
> Wishes to be filed (by Jamie Wilkinson) after more testing
> * base-files
> Add /run/ directory
> * pam, shadow
> Allow either /etc/nologin or /run/nologin to prevent nonroot login
> * sysvinit:
> Touch /run/nologin (not /etc/nologin) when there is a delay
> before a shutdown.
> * util-linux
> Use /run/mtab for mount's statefile
>
> TODO for /etc/resolv.conf
> Overview:
> * /etc/resolv.conf -> /run/resolv.conf
> * Networking daemon pidfiles go in /run/
> * Resolv.conf-like files go in /run/resolver/interfaces/
> * DNS cache configuration file fragments go in /run//
> * "/etc/init.d/resolver reload" regenerates /run/resolv.conf
> and calls DNS cache update scripts in /etc/resolver/update.d/
> * libc6
> * Create /etc/init.d/resolver script to:
> * Do "run-parts /etc/resolver/update.d"
> * Write /run/resolv.conf which:
> * lists 127.0.0.1 first if some local nameserver is running
> * then lists other nameservers from /run/resolver/interfaces/*
> * As B. Link and others have noted, this will have to be done
> with some care.
> * Change postinst to install symlink in rcS.d
> * bind
> * Create script /etc/resolver/update.d/bind to:
> * Write a "forwarders { ... }" statement to
> /run/bind/named.conf.options.forwarders containing
> the nameserver adresses from /run/resolver/interfaces/*
> * Then do "/etc/init.d/bind reload"
> * Change the /etc/bind/named.conf.options file to include
> /run/bind/named.conf.options.forwarders within the
> "options { ... }" statement.
> * dnscache
> * Something similar
> * ppp
> * Change /usr/sbin/pppd to:
> * Store PID in /run/, not in /var/run/
> * Create script /etc/ppp/ip-up.d/resolver to:
> * Write the lines:
> nameserver $DNS1
> nameserver $DNS2
> to /run/resolver/interfaces/$PPP_IFACE
> * Then call update-resolver
> * Create script /etc/ppp/ip-down.d/resolver to:
> * Delete /run/resolver/interfaces/$PPP_IFACE
> * Then call update-resolver
> * pump
> * Add /etc/pump directory
> * Change /sbin/pump to:
> * Store PID in /run, not in /var/run
> * By default, don't write /etc/resolv.conf
> * Run /etc/pump/up after configuring interface, furnishing
> $IFACE and nameserver addresses $DNS1 and $DNS2
> * Add script /etc/pump/up to:
> * Write the lines:
> nameserver $DNS1
> nameserver $DNS2
> to /run/resolver/interfaces/$IFACE
> * Then call update-resolver
> * Add script /etc/pump/down to:
> * Delete /run/resolver/interfaces/$IFACE
> * Then call update-resolver
> * Move pump.conf under /etc/pump
> * dhcp3-client
> * Change /sbin/dhclient to:
> * By default, store PID in /run, not in /var/run
> * Change /etc/dhcp3/dhclient-script to:
> * Write resolv.conf information to
> /run/resolver/interfaces/$interface not to /etc/resolv.conf
> * Then call update-resolver
>
> TODO later
> * ifupdown
> * Wish that ifstate be moved under
Re: /run and read-only /etc
Overall I think it is wonderful to see support for read-only root being worked on. On Wed, 2003-04-09 at 15:41, Matthew Garrett wrote: > Jeremy Jackson wrote: > > (doing this with bind mounts) > > >2.2 kernels are out though. > > As are BSDs. I have no idea whether the Hurd supports bind mounting. > Can it be assumed that all systems that may use this support ramdisks? What other schemes would allow a read-only root? Mounting a small fs on /run (although I hope it's not in the root directory)? > In most cases, just moving the files somewhere more sensible like > /var/run is sensible. The only argument should be over files that need > to be written before /var has been mounted, of which there should be a > very small number. It should be possible to deal with this in a simple > fashion. The technique involving bind mounts can be done with a regular mount, it would just take a few more steps: Mount ramdisk or whatever other rw fs on /etc/run very early in boot. Whatever needs to scribble in it does so, and everything works. If later the root FS is mounted rw, copy contents of /run to temp dir, unmount /etc/run, clear it out, then copy it all back. I think it's the least invasive technique, although I agree that some things that are messing about in /etc and can do it in /var should be fixed. -- Jeremy Jackson <[EMAIL PROTECTED]>
New project proposal: debian-lex
I am interested in coordinating a new sub-project called Debian-Lex, which would be Debian for Lawyers, akin to the Debian-Med, Debian-Jr and DebianEdu projects. Hopefully, these sub-projects will evolve into Bdale's idea of flavours (flavors, but I'm Australian) of Debian. I am a lawyer and also an IT consultant, which makes me one of a small handful of people who have a foot firmly in both camps. I have written for my local Law Society's magazine on free software for the legal office, but the lack of a packaged Linux system for lawyers does seem to be impeding the take-up of Linux within law firms, particularly on the desktop. The Debian-Lex project would in part just contain some obvious selections from the existing pool such as OpenOffice.org, Evolution and Gnotime, but it would also need some other packages that aren't yet in Debian such as SQL-Ledger (although this has been ITP'd), and I intend to put together a database schema that will serve as the basis for a legal client and matter database. If there are no major objections within the developer community I will liaise with the appropriate people to get this moving, and post for expressions of interest to the debian-users list to see if there are any other lawyers out there who would like to help. -- JEREMY MALCOLM <[EMAIL PROTECTED]> Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger. signature.asc Description: This is a digitally signed message part
Re: New project proposal: debian-lex
On Sat, 2003-04-19 at 23:57, Andreas Tille wrote: > On 19 Apr 2003, Jeremy Malcolm wrote: > > > I am interested in coordinating a new sub-project called Debian-Lex, > Could you please explain the naming "lex" for non English speakers? > > In general I really like your idea because I think those internal > projects are an important way to fit the needs of our users. I > would recommend to read the slides of my talk about internal projects > and also follow rhe link to the Subproject HOWTO. OK, thanks. Here (http://people.debian.org/~terminus/debian-lex/) is a rough Web page which I have shamelessly plagiarised from your Debian-Med project. I will contact the appropriate people in the mailing list and Web page groups to see if we can get this formalised. I have a preliminary list of packages (or proposed packages) that I would want to see as part of Debian-Lex, and I will contact those developers also. -- JEREMY MALCOLM <[EMAIL PROTECTED]> Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger. signature.asc Description: This is a digitally signed message part
[Debian-Lex] Packages and helpers for Linux for lawyers sub-project
As you may have noticed, Debian-Lex, the nascent Debian-for-lawyers sub-project, made DWN today, and I've had some expressions of interest off-list from that. We're still not officially launched yet though, until the list people create a list for us, so debian-devel will remain the point of contact until then. I'm also cc'ing debian-users on this mail because I am sure there are some non-developer lawyers who will be interested in getting involved, and I'm bcc'ing about a dozen upstream maintainers of packages that are proposed for inclusion in the project, but who might not want their addresses on Usenet. For these and others who came in late, our URL is http://people.debian.org/~terminus/debian-lex (until we are official and the Web people give us some proper space). So for starters we're mainly interested in what DFSG free packages are out there for lawyers, courts or legal administrators, that I don't already know about, that we can look at packaging into Debian-Lex. The current list (including, however, a number of vaporware packages) is found on the Web site. It also includes a few non legal-specific packages, but this needs to be fleshed out. Of the packages that are not vaporware and not already in Debian, I intend to package some of them myself, and I'm cc'ing the maintainers who have ITP'd GnoTime and SQL-Ledger to see if they have any news on their progress. One thing I am not confident at is PHP, so it would be good to have someone on board who can evaluate the PHP-based packages for possible inclusion and to package them if they come up to scratch. We are also interested in hearing about forms, templates, schemata, and documentation in use by lawyers with free software that can be packaged to support the main packages, and I already have a bundle of OpenOffice.org templates for the Family Law courts in Australia to start us off in this regard, and a set of SQL-Ledger accounts (including scripts to import time data from GnoTime). There are many other things to get going on but these are for starters. Also, we need to start the ball rolling in order to convince the powers that be to make us official. :-) Volunteers to help? -- JEREMY MALCOLM <[EMAIL PROTECTED]> Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger. signature.asc Description: This is a digitally signed message part
[Debian-Lex] Interview with subproject leader
the time of the next official Debian release, then by the time of the following release. Meanwhile, components of the Debian-Lex project will be released into Debian's unstable branch in incremental stages. Regardless of whether you are a Debian developer, or a software developer of any sort, we would welcome your input into the project. -- JEREMY MALCOLM <[EMAIL PROTECTED]> Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger. signature.asc Description: This is a digitally signed message part
Re: Storage (8*IDE HDs) any experiences?
On Fri, Apr 27, 2001 at 12:48:52PM +0200, Russell Coker wrote: > > See http://www.coker.com.au/~russell/hardware/46g.png for some quick > benchmark results showing the differences between a single IDE > drive, two drives on separate channels, and two drives on the same > channel. Hm. The server returns a MIME type of text/plain for that PNG file. You might want to get that looked at. Jeremy -- Jeremy D. ZawodnyWeb Geek, Perl Hacker, Yahoo! http://www.zawodny.com/jzawodn/ [EMAIL PROTECTED]
OT: Re: Fwd: Re: uptime
On Mon, Sep 17, 2001 at 12:09:52AM +0200, Martin F Krafft wrote: > > > The Policy Editor, OTOH, is quite nice. > > sure, but there are better. i forgot the name of the one i have in > mind, i'll post it tomorrow from the office. Please don't. It's already off-topic. -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! <[EMAIL PROTECTED]> | http://jeremy.zawodny.com/
Bug#521409: ITP: python-netfilter -- Python modules for manipulating netfilter rules
Package: wnpp Severity: wishlist Owner: Jeremy Laine * Package name: python-netfilter Version : 0.5.6 Upstream Author : Jeremy Lainé * URL : http://opensource.bolloretelecom.eu/projects/python-netfilter * License : GPLv3 or later Programming Lang: Python Description : Python modules for manipulating netfilter rules These Python modules act as a wrapper around iptables to manipulate the Linux kernel's packet filtering tables. Typical applications include building firewalls or network access controllers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534125: ITP: latex2mathml -- LaTeX2MathML is a php5 written program which converts LaTeX math formulas to MathML presentation markup.
Package: wnpp Severity: wishlist Owner: Jeremy Oden * Package name: latex2mathml Version : 0.1.0 Upstream Author : Jeremy Oden * URL : https://sourceforge.net/projects/latex2mathml/ * License : BSD Programming Lang: PHP5 Description : LaTeX2MathML is a php5 written program which converts LaTeX math formulas to MathML presentation markup. latex2mathml is a powerful php5 class that can be used to convert LaTeX math formulas to Presentation MathML . This program can be used as command line, using php5-cli . -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#534751: ITP: latex2mathml -- Convert LaTeX math formulas to MathML
Package: wnpp Severity: wishlist Owner: Jeremy Oden * Package name: latex2mathml Version : 0.0.0 Upstream Author : Jeremy Oden * URL : https://sourceforge.net/projects/latex2mathml/ * License : BSD Programming Lang: PHP Description : Convert LaTeX math formulas to MathML latex2mathml is a powerful php5 class that can be used to convert LaTeX math formulas to Presentation MathML. This program can be used as command line, using php5-cli. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: SV: MATE 1.8 has now fully arrived in Debian
On 2014-06-25 14:03:20 -0700 (-0700), Russ Allbery wrote: > This doesn't change anything else that you point out, but that's > why you run startx & and then log out of the virtual console. On my workstations and travel machines I have: alias x='startx&exit' ...in my ~/.bash_aliases file. Works like a charm. But given that I prefer ratpoison and a screen full of xterms, I'll bow out of the rest of this thread. -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140625235155.ga1...@yuggoth.org
Bug#753367: Solved
Install was from USB. Setup was not removing entry for USB drive from fstab upon completion of installation. Removed line for USB from fstab. Functions normally. -- Jeremy "You can ignore reality, but you cannot ignore the consequences of ignoring reality." - Ayn Rand
Re: Standardizing the layout of git packaging repositories
On 2014-08-16 01:15:45 +0800 (+0800), Thomas Goirand wrote: [...] > Yes. Producing orig.tar.xz out of upstream tag should be industrialized, > and written in "some" tools, which we would all be using. I currently > do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own > packages. However upstream may build tarballs through a (hopefully repeatable/automated) process at release time, publish checksums and signatures for them, et cetera, and prefer packagers use those as the original tarballs for official release versions. I understand needing to create "original" tarballs yourself in cases where there are none (for example making development snapshot packages), but when upstream provides them it seems like it would make sense to use those tarballs in lieu of trying to recreate your own from tags in their version control system. I have become increasingly wary now that more and more slipshod upstreams with no release process have created a need for package maintainers to fabricate one on their behalf, the kludge can get turned back around on upstreams with formal, traditional release processes and used as a convenient excuse to discard their output in the name of consistency. *Please* don't replace upstream's release tarballs just because they have a VCS. -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815230550.gp1...@yuggoth.org
Re: Standardizing the layout of git packaging repositories
s to make the tarball you eventually end up using in your source package anyway seems like a duplication of effort. > If by "traditional release process" you mean wasting human time, > computer CPU, and network bandwidth, to build old 80ies fashioned > tarballs (that is: with .gz compression and no PGP checksums), > which by the way loose all the commit history and such, I am > wondering what you are worrying about. That's useless these days, > if upstream is using Git. A tag is enough, and it's even better. [...] I recall it suggested on Debian mailing lists and other howtos/articles even in very recent years that to be a "good upstream" you should release tarballs and publish signed release announcements including their checksums, and that upstreams who only "release" software as a tag in a VCS are making things harder for everyone downstream. Pretty much all the projects on which I do upstream work provide these things because they have been explicitly requested by distribution packagers. If the modern trend is to just assume that nobody upstream will bother to release tarballs any longer and expect every distribution to do it themselves only slightly differently, then I should revisit those assumptions and perhaps no longer bother. Is this a generally consistent opinion across Debian package maintainers now? Across other distributions as well? > I also think it's best to be able to build from the git repository > rather than what's been generated out of it, because that's what you > will do if you want to contribute to the upstream project. Makes sense. So then why does Debian (and for that matter so many other distributions outside of the *BSDs) base source packages on tarballs rather than building binary packages directly out of a VCS? It seems a contradiction on the one hand to assert that you don't need tarballs any longer but then on the other hand still rely on them completely. -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818204021.gv1...@yuggoth.org
Re: Standardizing the layout of git packaging repositories
On 2014-08-17 16:20:34 +0800 (+0800), Thomas Goirand wrote: > But then in which way will you check that the said upstream tarball, > without any upstream checksum, is valid? At least tags are > signed... You keep coming back to the assumption that upstreams don't provide signed lists of checksums. I would wager that the percentage of upstreams who sign VCS tags are probably (within reasonable margin of error) roughly equivalent to the number who sign lists of file checksums or provide detached signatures of the release files themselves, so this argument seems specious. > Also, why the forensic investigation wouldn't instead check that the > generated tarballs are really based on the correct PGP signed tags? [...] If there is a release-time build step between the VCS tag and the tarball, then this can become nontrivial. -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818204725.gw1...@yuggoth.org
Re: Standardizing the layout of git packaging repositories
On 2014-08-20 02:32:10 +0800 (+0800), Thomas Goirand wrote: [...] > Good! For the moment, it has worked nicely, apart from the fact that > *some* upstream, like Jeremy Stanley, don't like it. I honestly feel > sorry about that, especially with people like Jeremy and other OpenStack > folks which are doing truly awesome work, and for which I have a lot of > respect. > > And would like to let him understand the reasons that are pushing me to > work this way. I also feel like it's mostly a non-issue, for which > there's no reason to be that picky (just let go, Jeremy? :)). [...] Fair enough! I will admit (having been a devoted Debian user in personal and large commercial settings for the past 15+ years but only an occasional packager) that I'm very impressed at how you keep up with the extreme volume of packaging you do day to day, and ultimately feel however you manage to maximize your efficiency is best for everyone. My main upstream takeaway from this is that we should perhaps be considering tarballs as a target-specific packaging format (PyPI et al) in and of themselves any longer, rather than a general release item and stop placing as much focus on them in release announcements if packagers are mostly just consuming source directly from our version control systems now. Thanks for considering my (apparently outdated) arguments, and keep up the good work! -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014082814.gx1...@yuggoth.org
Re: Standardizing the layout of git packaging repositories
On 2014-08-20 02:21:35 +0800 (+0800), Thomas Goirand wrote: > Well, for the changelog of OpenStack stuff, the FTP masters have > express their opinion that it's just too big to be in every > packages, so I have to *not* include them. Understandable for some of those larger projects with many thousands of changes (and I think python-pbr has introduced short-form changelog generation options in more recent releases to reduce the level of detail considerably so it hopefully becomes less of an issue over time). > As for the AUTHORS file, it isn't helpful at all from a package > maintainer stand point. What's important is who is the copyright > holder, and this should go directly in debian/copyright. To this > day, I have no way to have that file fully right, considering how > many contribution there is in OpenStack. I've raised that issue on > the OpenStack dev list, but I don't think my message went through > the correct way. [...] There still seems to be some legal contention around Apache License 2.0 expecting an authors list for a project. And I agree copyright license headers are sort of a subjective issue if a given committer feels their contribution to a particular file is or is not significant enough to amend the years/holders there (also in many cases the authors are not the copyright holders, but rather their employers are, so the authors list can be essentially irrelevant where copyright is concerned). > Please name the "et cetera". Because it is my understand that it > is the only thing I would "miss". Well, as you mentioned, for Python packages the MANIFEST.in could be getting autogenerated based on .gitignore exclusion patterns or other details. Project version numbering could also be inferred from git tags and embedded at release distribution time. If we're talking in a more general sense (not specifically *your* packaging work on OpenStack-specific projects), http://www.gnu.org/software/automake/manual/html_node/The-dist-Hook.html is a fairly classic example of where developers can expect to be able to do just about anything between the development and release states of their source code (like how python setup.py sdist could be written to do anything while generating a tarball). Asserting that the development and release state of source should be identical represents a relatively nontrivial paradigm shift, in my opinion (not that I think it's a bad idea, just that it indicates a change in attitudes and behavior for upstream developers as well as packagers downstream). > If you think that's a problem, then I can add such a README in all > of the packages I maintain this way, no problem. Altering the > version string would be annoying though (I'd have to retag after > each "git fetch upstream"), but if you insist really a lot, I may > consider it. It will just take me a *long* time to write the > READMEs though (since there's more than 100 packages which I > maintain this way), but I think it's a good idea. [...] It only seems like a problem to me because it was, for a long time (no longer?), convention that if you generated your own tarballs for a source package (for repacking needs or otherwise) then you adjusted the version and otherwise made it obvious you as a packager had done so. Not taking those steps implied that you were asserting these tarballs you were redistributing were the "original" upstream release tarballs. The easiest way I can see as an upstream to avoid confusion around this is to stop releasing or otherwise emphasizing tarballs, especially if downstream packagers won't be using them anyway and will replace them with their own because their tools/workflows are optimized to do that instead. -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820005735.gy1...@yuggoth.org
Bug#671779: ITP: qdjango -- Cross-platform C++ web development framework
Package: wnpp Severity: wishlist Owner: Jeremy Lainé * Package name: qdjango Version : 0.2.0 Upstream Author : Jeremy Lainé * URL : http://code.google.com/p/qdjango/ * License : LGPL Programming Lang: C++ Description : Cross-platform C++ web development framework QDjango is a web framework written in C++ and built on top of the Qt library. Where possible it tries to follow django's API, hence its name. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120506211236.8014.45961.reportbug@sharky
Bug#678920: ITP: libzapojit -- library for accessing SkyDrive and Hotmail
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Jeremy Bicha * Package name: libzapojit Version : 0.0.2 Upstream Author : Debarshi Ray * URL : http://git.gnome.org/browse/libzapojit * License : LGPL-2.1 Programming Lang: C Description : library for accessing SkyDrive and Hotmail libzapojit is a GLib-based library for accessing online service APIs using the Microsoft SkyDrive and Hotmail REST protocols. libzapojit is a new dependency of gnome-documents for GNOME 3.6, enabling Microsoft SkyDrive support as an alternative to the already existing Google Docs support. I intend to co-maintain this library with the Debian GNOME Team. http://debarshiray.wordpress.com/2012/05/31/gnome-documents-skydrive/ Thanks, Jeremy Bicha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmaqrj-tkhlf5am-fz+g+odikadhms0ijdufrqudyae...@mail.gmail.com
Re: Recommends for metapackages
On 11 July 2012 14:21, Noel David Torres Taño wrote: > Installing N-M breaks unrelated software. Hi! I don't claim to be a networking expert, but I believe half the conversation here is based on wrong or outdated information. I encourage those who think NetworkManager (NM) doesn't play well with ifup/ifdown to please read http://wiki.debian.org/NetworkManager#NetworkManager_in_Squeeze Furthermore, not having NM running breaks the Network panel in System Settings (gnome-control-center). NetworkManager makes connecting to WiFi points much much easier, while at the same time NOT breaking wired connectivity. Oh, and NM works just fine for USB tethering with my Android phone too. GNOME considers NM to be part of GNOME Core, therefore gnome-core depends on it. If you're allergic to NM, either don't install gnome-core; let NM install but tell it never to run; or follow one of the several workarounds already posted to this list. Thanks, Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmzvrd2m1riqq51pxpca0zuey-eluvchczqt0mmzrw3...@mail.gmail.com
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
On 9 September 2012 23:21, Ztatik Light wrote: > According to popcon, Xfce is more common on Debian than GNOME... And How do you figure that? http://qa.debian.org/popcon.php?package=meta-gnome3 http://qa.debian.org/popcon.php?package=xfce4 Just looking at popcon, GNOME is installed several more times as much as XFCE. Even gnome-shell has more installs than xfce4-panel despite GNOME Shell having not been included in a stable Debian release yet. Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmy6nngvdj9j_9mtozgtad18f2zvp6cenvl2oaebzgv...@mail.gmail.com
Re: CD1 without a network mirror isn't sufficient to install a full desktop environment
On 11 September 2012 08:06, Ian Jackson wrote: > Based on this, I think there is at the very least no reason to > reverse the decision to switch the Debian default to xfce. Except as Paul said, the decision to make XFCE default for Wheezy has not been made so it can't be reversed. Jeremy Bicha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmyy3xrukcng3to015kmqpxgxzw7wp8yw+rvjj906om...@mail.gmail.com
bzr (was: Re: Debian systemd survey)
On 22 May 2013 22:02, Chow Loong Jin wrote: >> [...] Bazaar (which seems to have been abandoned by >> upstream with >2000 open bugs [1]) [...]. > > On the other hand, it would be nice if you keep your FUD to the minimum. > Bazaar > doesn't look abandoned[1], and >2000 open bugs is not uncommon. Nautilus and > Rhythmbox themselves have >1000 open bugs each. > > [1] https://code.launchpad.net/bzr Two commits this year? The only thing that makes it not completely abandoned by upstream is that occasionally there are a few maintenance bugfix commits done. For the record, I do use bzr (with http://jameswestby.net/bzr/builddeb/user_manual/merge.html ) in my normal Ubuntu/Debian packaging workflow. I haven't figured out how to git to work as nicely for that usecase yet. Jeremy Bicha -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaajcmzsv+wibph7dmoce2fq4d3cmtaqoe48axuogzw+6pd...@mail.gmail.com
Re: Default desktop for jessie Was: Re: Debian/Wheezy general rant ...
On 2013-06-05 15:02:35 -0700 (-0700), Russ Allbery wrote:
[...]
> Did I miss anything?
I don't understand at all how you could have missed such a prime
opportunity to rile up the vi vs. emacs debate while you were at
it... or am I showing my age?
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130605225422.gs1...@yuggoth.org
Re: default MTA
On 2013-06-12 02:09:24 +0800 (+0800), Chow Loong Jin wrote:
> On Tue, Jun 11, 2013 at 08:01:58PM +0200, Daniel Pocock wrote:
> >
> > What about replacing SMTP?
>
> With what?
With ESMTP, of course!
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130611205635.ga1...@yuggoth.org
Re: default MTA
On 2013-06-11 23:50:01 +0200 (+0200), Daniel Pocock wrote:
> Something that doesn't have these limitations:
>
> http://tools.ietf.org/html/rfc2487#section-7
[...]
That basically just makes the case for relying on (E)SMTP only for
transporting messages, but leveraging OpenPGP or S/MIME to provide
authentication and confidentiality where required (or for anonymity,
Mixmaster et al).
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130611220230.gb1...@yuggoth.org
[OT] SMTP bad (was: default MTA)
On 2013-06-12 08:08:17 +0200 (+0200), Daniel Pocock wrote:
> On 12/06/13 00:02, Jeremy Stanley wrote:
> > That basically just makes the case for relying on (E)SMTP only for
> > transporting messages, but leveraging OpenPGP or S/MIME to provide
> > authentication and confidentiality where required (or for anonymity,
> > Mixmaster et al).
>
> OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't
> really) encrypt the headers/envelope
[...]
Apologies if that message made it past the sarcasm filter, but I was
being flippant. As for anonymity, that's why I mentioned a type II
remailer... you can use Mixmaster without nyms as long as you don't
care about the recipient being able to respond to you. And if you
do, well that's pseudonymity not anonymity. (Though I really think
you meant "confidentiality" when you wrote "anonymity" there?)
The situation with SMTP is not so dire as you paint it, you simply
need to implement your own cryptography on top of it and be aware of
the characteristics it provides (for example put your real subject
in the message body if using OpenPGP, onion-routing/remailers if you
don't want an eavesdropper to know who you're talking to, et
cetera). Hop-by-hop opportunistic encryption on the "honor system"
does little more than give a false sense of security, but mailadmins
hopefully already know this long before they contemplate twisting
the shiny STARTTLS knob for remote deliveries?
In short, encrypted SMTP is there to protect your login credentials
when connecting directly to a known smarthost, and if you're doing
it right you're using proper certificate validation (at least TOFU
anyway). Any use beyond that is either misguided fantasy or a sales
pitch for the PKI (CA/TTP) cartels. As long as you accept the nature
of SMTP and use it in the ways it's intended, it's a perfectly fine
protocol which has withstood several decades of pounding while its
detractors have never managed to successfully replace it with
something better.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130612193519.gd1...@yuggoth.org
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 20 July 2013 08:17, Marc Haber wrote: > On Sat, 20 Jul 2013 11:27:58 +0200, Josselin Mouette > wrote: >>If this is about kFreeBSD, it would be nice and all to share the init >>system with these ports, but it should certainly not have an influence >>on the choice of init system for the Linux ports. > > Why? Because http://lists.debian.org/debian-devel/2013/07/msg00379.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMYX_wABY-TsZd0=Ga+rBK7BCq-t6KC8chXASDXnFgN=r...@mail.gmail.com
Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 21 July 2013 20:22, The Wanderer wrote: > I'm saying that it looks to me as if the lock-in to systemd would be > even stronger than the lock-in to sysvinit, and might well extend to the > point of even making it harder to implement another new alternative in > the first place. So let's never switch to anything better than what we have now unless we also support 1 or 2 alternatives simultaneously just to be safe. /s Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMaWbUDKK1eA=h2oWqR2L0M2wv-b=cp2oz1b-f_8hmx...@mail.gmail.com
Re: We need a global decision about R data in binary format, and stick to it.
On 2013-08-05 14:13:15 +0100 (+0100), Ian Jackson wrote:
[...]
> The other is the assertion that this particular case involves a
> generated data table. If this is the case then the source package
> needs to contain the source code which generates the table - and,
> really, it should regenerate the table during the build.
[...]
No argument on the first, but the second sets a bad precedent if
interpreted strongly. For example I have a program which relies on a
fairly large set of correlative data requiring hours of expensive
computation to generate. In the source package I include the
original data on which the resulting tables are based and provide a
means to regenerate it on the fly at package build time, but disable
it by default so that it doesn't chew up build resources
unnecessarily.
Since I need to generate the correlation data for other (non-Debian)
users of the software anyway, I ship the generated files in the
source package too and just include them in the binary package
(along with instructions and tooling for the end user to be able to
build datasets they can use to override the default ones provided).
While my example is Python rather than R, I expect it's
representative of situations for many scientific tools. Perhaps some
guidance on when this tactic is or is not appropriate would be
beneficial.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130805151657.gd1...@yuggoth.org
Re: We need a global decision about R data in binary format, and stick to it.
On 2013-08-05 16:41:13 +0100 (+0100), Ian Jackson wrote:
[...]
> There should IMO be a standard way to request a source package to do
> from-scratch rebuilds for this kind of thing, for QA purposes.
I absolutely agree. If there were a standard make target or envvar
for this purpose I would gladly implement it in my debian/rules.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130805155503.ge1...@yuggoth.org
Why IceApe?
I know Firefox was rebranded IceWeasel because of the problems with the Mozilla trademark for Firefox, but as far as I know there is no such trademark for SeaMonkey and if there is, it's not owned by Mozilla, it's owned by the SeaMonkey project. Why, then, is it rebranded to IceApe? Can't Debian just distribute it as SeaMonkey? Distributing it as IceApe makes it tricky to figure out how extension compatibility works between SeaMonkey and IceApe, and it's hard to support IceApe considering you could probably count the number of IceApe users on the fingers of one hand. -- Best regards, Jeremy Morton (Jez) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5274de41.4020...@gmail.com
Re: Bug#648286: ITP: r8168 -- Realtek r8168 device driver for Linux (DKMS version)
2011/11/10 onlyjob > Thanks, Julien. > > I see you've made r8168-source package as well - nice. > I will introduce support for module-assistant if we agree on package > inclusion. > > > I would second that as I have another problem with r8169 which doesn't > > support support resuming from suspend/hibernate. I've been using r8168 > for a > > couple of weeks without any issue. > > > > I have even built a package for my own use [0] in case this can help. > > > > I will report a bug against r8169 as advised by Ben as soon as I find the > > time to clearly describe the issue. > > > > Cheers, > > Julien > > > > [0] http://git.kirya.net/?p=debian/r8168.git;a=summary > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/canbdodwtdz8coath0ws9b53gse3wmudef58jzlora5ss3z6...@mail.gmail.com > > BTW, I just want to say that using the r8168 driver correct the problem that I get with my network card when I reboot directly in debian from windows, without closing the computer first. It's about the WOL thing that r8169 doesn't support well or something like that.
Re: Popularity of bzr-builddeb and dh-make
On 2012-10-17 23:55:08 +0200 (+0200), Philipp Kern wrote:
> am Wed, Oct 17, 2012 at 05:48:39PM -0400 hast du folgendes geschrieben:
> > > With the danger of being sued if you put up the result onto the public
> > > interwebs.
> >
> > Could you please expand on that? Logo / trademark reasons or license
> > issues?
>
> it's not very hard to find https://dev.launchpad.net/LaunchpadLicense
>
> It's designed not to be run outside Canonical except for development.
> And it's not just the logo/trademark, no. I'd completely understand that.
The section to which you seem to be referring is relevant
specifically to "image and icon files in Launchpad." If you replace
those with your own artwork or some other released under a
compatible license and respect any other requirements of the AGPLv3,
it doesn't sound like there should be any concern on the part of
Canonical. What am I missing?
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121017221635.gl22...@yuggoth.org
Re: Bug#692863: ITP: heimdall -- tool for flashing firmware on Samsung Galaxy S devices
On 9 November 2012 16:43, Steve Langasek wrote: > * Package name: heimdall > Version : 1.4~rc2 > Upstream Author : Benjamin Dobell > * URL : http://www.glassechidna.com.au/products/heimdall/ > * License : MIT/X11 > Programming Lang: C++ > Description : tool for flashing firmware on Samsung Galaxy S devices > > Heimdall is a tool for flashing firmware (aka ROMs) onto Samsung Galaxy S > devices over a USB connection. It accomplishes this using the same > protocol as Odin, Samsung's internal Windows-only firmware updater. > > > The naming of this tool is entirely logical from the upstream's perspective, > given that there are other related pieces of software called "Odin" and > "Loke". However, there's an unfortunate namespace collision here with the > Kerberos implementation Heimdal. Suggestions welcome on how to qualify > the source package name so that the packages are more than one letter off > from one another... There's another ITP that suggested heimdall-flash: http://bugs.debian.org/644520 Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMbYue2YsW3n9_qhe_q5Az_4=m7m_zzey_y20dza8tn...@mail.gmail.com
Re: Packaging MATE for Debian
On 3 December 2012 14:28, Stefano Karapetsas wrote: > As I already said you many times, MATE no longer uses these "obsolete" and > "duplicated" libraries. > > And, maybe you dont know, but we are already working with GNOME developers > to share efforts with them. Just some examples: with yelp developer, to use > yelp as documentation viewer and yelp tools to build documentation; with > evince developers to share libriaries and have only separated UI. And we are > working with GNOME to keep alive software no longer maintained too [1]. What's so bad about evince that you need to use a forked version anyway? Or gnome-icon-theme, gnome-keyring, gnome-terminal, etc. Jeremy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAajCMaYguJVapK-Yra5irs=drnlgdr4c5uvivm-vhvondc...@mail.gmail.com
Re: Contributor agreements and copyright assignment
On 2012-12-04 12:42:33 -0800 (-0800), Russ Allbery wrote:
[...]
> The main issue for some of us is not so much the ethical
> objections to these sorts of agreements but rather the fact that
> our employers flatly are not interested in signing anything of the
> sort, ever, with anyone. Much of my free software work is done as
> part of my day job, and my employer is unwilling to sign any of
> these agreements (but is fine with me releasing my work under free
> software licenses).
Conversely, my job is to contribute to and support development
effort on particular free software projects, so I am releasing what
is essentially my employer's work for hire product of my own accord.
In this case the CLA they've signed on my behalf serves as a notice
in writing that they're aware of the arrangement, as well as a
guarantee against them claiming copyright infringement by the
projects to whom I am contributing.
--
{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
FINGER( fu...@yuggoth.org ); IRC( fu...@irc.yuggoth.org#ccl );
PGP( 43495829 ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121204210951.go22...@yuggoth.org
Re: Feedback
On 2012-12-25 22:50:57 +1000 (+1000), Mistikos Nik wrote:
[...]
> Debian use to be really popular. Now only old people use it.
[...]
I suddenly feel very old. What distribution do twelve-year-old
trolls use these days, if not Debian? Have we lost our key
demographic?
--
{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
PGP( 48F9961143495829 ); MUD( kin...@katarsis.mudpy.org:6669 );
FINGER( fu...@yuggoth.org ); IRC( fu...@irc.yuggoth.org#ccl ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121225135117.gq6...@yuggoth.org
Re: Knowing the release names in advance
On 2012-12-31 10:38:54 -0500 (-0500), Kris Deugau wrote:
> Serious question - is this a real manpage? If so, which package is
> it in?
[...]
It's introduced in Wheezy and available in backports for Squeeze:
http://packages.debian.org/distro-info
http://bugs.debian.org/559761
--
{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
PGP( 48F9961143495829 ); MUD( kin...@katarsis.mudpy.org:6669 );
FINGER( fu...@yuggoth.org ); IRC( fu...@irc.yuggoth.org#ccl ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121231161436.gu6...@yuggoth.org
Re: debian/* license of non-free packages
On 2013-01-10 17:54:28 + (+), Bart Martens wrote:
> I guess you meant : It's conventional (although not entirely
> legally sound) in the free software community to just assume that
> the copyright of any patch submitted without any explicit
> copyright and license statement is transferred (given) to the
> copyright holders of the upstream software.
And in many cases it's convention to expect the patch contributor to
patch the copyright statement of the corresponding files as part of
their contribution, if they feel it's necessary. Many of the
projects I work on expect contributors to do precisely this as a
routine part of nontrivial patch submissions.
--
{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
PGP( 48F9961143495829 ); MUD( kin...@katarsis.mudpy.org:6669 );
FINGER( fu...@yuggoth.org ); IRC( fu...@irc.yuggoth.org#ccl ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130110180117.gs6...@yuggoth.org
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-08 14:52:48 +0100 (+0100), Thomas Koch wrote:
[...]
> http://openstack-ci.github.com/publications/
[...]
I'm one of the core developers for the team which manages all that
tooling and integration for the OpenStack Project, so I'm happy to
discuss some of the nitty-gritty details, any gotchas/unpleasantness
we experience and how we work around it.
A better starting URL is http://ci.openstack.org/ and we're also
very active on freenode in #openstack-infra for those who desire
more synchronous conversation.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130308143448.gv29...@yuggoth.org
Re: Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-08 12:44:36 -0800 (-0800), Russ Allbery wrote:
> Thank you very much for working on this! We use Gerrit extensively but so
> far just haven't packaged it because it was too intimidating.
Agreed, if Gerrit gets packaged in Debian/Ubuntu I'll likely push
OpenStack to start using DEBs of it on our CI infrastructure (though
chances are we'll still rebuild from the source package because we
carry patches for features in which Google has thus far been wholly
disinterested).
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130308215201.gb29...@yuggoth.org
Re: RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
On 2013-03-09 23:33:47 +0800 (+0800), Thomas Goirand wrote:
[...]
> I also need to understand how to secure Jenkins. Because
> by default, it's impressive how much Jenkins is a security
> hole where you can execute any command. I was tempted
> to file a bug report against the package because of it. Then
> I saw #697617 and #700761, then gave up... :)
[...]
Yes, it's a chore to keep up with the security vulnerabilities for
Jenkins, particularly if you're following mainline instead of stable
since updates become a grab bag of (sometimes unintended) API
changes as well as new bugs and regressions. We try to be as
proactive as we can, scrape the security index on their wiki and
just plain shutdown Jenkins services on our servers until we can
validate the security fixes and get them applied in production. It's
not for the faint of heart.
At this point we're close enough to having Jenkins interactions
externally integrated with our other systems that its WebUI isn't
much use except for administrative functions. I expect it's not too
far in the future that we'll be able to lock it down such that only
administrators will have access to that interface.
--
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130309155027.gg29...@yuggoth.org
