Re: watch files and weird version numbers
does ([0-9].[0-9])([0-9]?) help ? i noticed having 2 pairs of () added a . in the Debian version. Regards, -- Niv Altivanik <[EMAIL PROTECTED]> Debian::GNU/Linux::Addict, Wannabe Debian Developper, please test my packages: http://cxhome.ath.cx/debian pgpuQ7Q0xO7NZ.pgp Description: PGP signature
Bug#754703: ITP: python-vertica -- native Python client for the Vertica database
Package: wnpp Severity: wishlist Owner: deb...@jbfavre.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-vertica Version : 0.2.3 Upstream Author : justin.be...@gmail.com, alex@uber.com * URL : https://github.com/uber/vertica-python * License : MIT Programming Lang: Python Description : native Python client for the Vertica database HP Vertica is a commercial column-oriented database. This package provides all the source, examples and documentation to easily connect to and interact with Vertica. I already use, and maintain, the package at work. I will take care of the packaging and maintain the package. I got help from Debian Developers Vincent Bernat and Sylvestre Ledru to prepare the package. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJTwpMVXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RTg0NUJBMjMwQ0I0RDQ0ODkwNjk4NDdC NERENTM2QUNGN0Q4NzM3AAoJELTdU2rPfYc3FLcP/RiET5ucHETzNwz9ZMrHXNcj hSqOQ9nyiqmPslWNhk6JekVoO4S+li1tHGuOIRc3Db1qXLIDZdSH0j3tjZUG/2+I 7tlZIkmpJSI6Z2AfX3ujnluEXMB7dLmwcvhrMy8sAtj2MHAb2eF+zK+hnOr4wbMh pBaKIQqwihzch/3QAiymmt4QJVQSclsQFVYFC8PZG4E3AGDdo5kA1iOSYAgnW3gy xdHqj6/mqOa4nyHK61IVj1kW2A2TCfob6RtfpMyOXXgSeJ8I94Rv8RP0Aiqdfl8G 6OLjOjGY8ds76WFIzT86xp326N2+mvq/W5/B4/NydWx8fPfNGVEGegSZG6KJW43V +mSwQ6VITO9isD/nyDZrQvhg1tTZNO9iA/H+ZatOJYtGldc079UXj7Kr37OgOP8E O3mgdbt9rxRl+uaTsfCitjpvUiaV6nBWRccs1KNikQwCZ0Bkgv5JlvY8xMaWn+DH GxLsXHWkaLiJKBHemS57fm2Q/HhG4JL+6SPnDzjCJ4dj2+/EYXSQlv4lUxkBt30t p9oG74HZwdl1ZoL5DbqrfaUKpk4FCLSKxkyBFXA18SNbdMZ5Oh4xXOWJVN3LALuj DCRbavDLRN+1RXA7sCcm5xI8O35K4X5r1TQzg7FVeqLr5kon8JmAV/hOjXJh4T54 /7gh4GSRntGRNuFpwFT0 =MlnH -END PGP SIGNATURE- -- 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/20140713140925.2365.87477.report...@jbfavre.lan
Re: Providing official virtualisation images of Debian
On 7/25/2011 6:27 PM, Moritz Mühlenhoff wrote: Hi, I believe it's high time we start to providing Debian in form of official virtualisation images. In contrast to the ISOs currently provided it allows a quicker evaluation/testing of Debian (and can also be very useful for testing (e.g. someone wrote on debian-release that he doesn't have access to oldstable/stable systems, with prepared virtualisation images that would no longer be an issue). For many setups this could even replace the installer since software selection and hostname can easily be tweaked post-install. I think it's sufficient for starters to provide images for stable (they can be updated for every few point updates if needed). What virtualisation solutions should be supported? - Virtual Box seems like a natural candidate since it's free and included since Squeeze. - Vmware has a significant installed base and is relevant, although proprietary - Microsoft Virtual PC is likely also needed - Qemu - Citrix XenServer? For now I would recommend against pre-configured Citrix XenServer releases. I am a Citrix CCNA and I would not recommend that for this very reason. Debian is best set up in Citrix Xenserver from scratch. As far as VMware goes, I use that at home all the time. And with the freely available VMWare Player, I make virtualized Debian installs available to them all the time. -- 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/4e2defb9.2080...@fpsoft.net
Re: What would help the most?
Hi, I have the feeling, that this is some kind of semi-AI generated chat. I think we should stop it now. Imre, Nagy 2023. 10. 30. 2:29 keltezéssel, Lukasz Szybalski írta: On Sat, Oct 28, 2023 at 3:41 AM Paul Wise wrote: On Fri, 2023-10-27 at 14:00 -0500, Lukasz Szybalski wrote: > What is the minimum most value thing that would > help YOU accomplish your goals for Debian ? Check out this page if no-one gives anything more specific: https://www.debian.org/intro/help Paul, Marc, Andrey Thanks for replying. To narrow it down: *Vision of Debian:* Create a free operating system, freely available for everyone. *Goal:* Coding and Maintaining Packages <https://www.debian.org/intro/help> Testing and Bug Squashing <https://www.debian.org/intro/help> /In these 2 goals:/ What is the minimum most valuable thing that would help YOU accomplish your goals for Debian ? Thanks Lucas
Bug#1070800: ITP: evremap -- keyboard input remapper for Linux/Wayland systems
Subject: ITP: evremap -- keyboard input remapper for Linux/Wayland systems Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Yifei Zhan Severity: wishlist * Package name: evremap Version : 0.1.0 Upstream Author : Wez Furlong * URL : https://github.com/wez/evremap * License : MIT Programming Lang: Rust Description : keyboard input remapper for Linux/Wayland systems evremap works by grabbing exclusive access to an input device and maintaining a model of the keys that are pressed. It then applies your remapping configuration to produce the effective set of pressed keys and emits appropriate changes to a virtual output device. Because evremap targets the evdev layer of libinput, its remapping is effective system-wide: in Wayland, X11 and the linux console. (^ from project readme) It works well on my machines and supports more complex mapping (e.g. dual role key based on tapping/holding and M <-> N mapping (F3 -> Ctrl-K / Shift-K -> F5)) while maintaining a simple configure syntax.
Bug#1070829: ITP: wprs -- rootless remote desktop access for remote Wayland and x11 applications like xpra
Package: wnpp Subject: ITP: wprs -- rootless remote desktop access for remote Wayland and X11 applications like xpra X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Yifei Zhan Severity: wishlist * Package name: wprs Version : 0.1.0 Upstream Contact: Nicolas Avrutin * URL : https://github.com/wayland-transpositor/wprs * License : Apache 2.0 Programming Lang: Rust Description : rootless remote desktop access for remote Wayland (and X11, via XWayland) applications like xpra wprs implements rootless remote desktop access for remote Wayland (and X11, via XWayland) applications with supports for session resumption (running applications will survive wprsc disconnection and later reconnection and wprsc restarts). Currently only the the Core and XDG shell protocols are implemented and hardware rendering/dmabuf support is not yet implemented. Generally, wprs will aim to support as many protocols as feasible, it's a question of time and prioritization.
Bug#981565: ITP: golang-github-inexio-go-monitoringplugin -- Golang package for writing monitoring check plugins for nagios, icinga2, zabbix, etc.
Package: wnpp
Severity: wishlist
Owner: deb...@thola.io
* Package name: golang-github-inexio-go-monitoringplugin
Version : 0.0~git20201117.ec06ef4-1
Upstream Author : inexio
* URL : https://github.com/inexio/go-monitoringplugin
* License : BSD-2-clause
Programming Lang: Go
Description : Golang package for writing monitoring check plugins for
nagios, icinga2, zabbix, etc.
go-monitoringplugin Go Report Card
(https://goreportcard.com/report/github.com/inexio/go-monitoringplugin)
GitHub license
(https://github.com/inexio/go-monitoringplugin/blob/master/LICENSE)
Description Golang package for writing monitoring check plugins
for nagios (https://www.nagios.org/), icinga2 (https://icinga.com/),
zabbix (https://www.zabbix.com/), checkmk (https://checkmk.com/), etc.
The package complies with the Monitoring Plugins Development Guidelines
(https://www.monitoring-plugins.org/doc/guidelines.html). Example /
Usagepackage main
.
import (
monitoringplugin "github.com/inexio/go-monitoringplugin"
)
.
func main() {
//Creating response with a default ok message that will be
displayed when the checks exits with status ok response :=
monitoringplugin.NewResponse("everything checked!")
.
//Set output delimiter (default is \n) //response.SetOutputDelimiter("
/ ")
.
//updating check plugin status and adding message to the ouput
(status only changes if the new status is worse than the current one)
response.UpdateStatus(monitoringplugin.OK, "something is ok!") //check
status stays ok response.UpdateStatus(monitoringplugin.CRITICAL,
"something else is critical!") //check status updates to critical
response.UpdateStatus(monitoringplugin.WARNING, "something else is
warning!") //check status stays critical, but message will be added
to the output
.
.
//adding performance data err :=
response.AddPerformanceDataPoint(monitoringplugin.NewPerformanceDataPoint("response_time",
10, "s").SetWarn(10).SetCrit(20).SetMin(0)) if err != nil {
//error handling
} err =
response.AddPerformanceDataPoint(monitoringplugin.NewPerformanceDataPoint("memory_usage",
50, "%").SetWarn(80).SetCrit(90).SetMin(0).SetMax(100)) if err !=
nil {
//error handling
}
.
response.OutputAndExit() /* exits program with exit code 2 and
outputs: CRITICAL: something is ok! something else is critical!
something else is warning! | 'response_time'=10s;10;20;0;
'memory_usage'=50%;80;90;0;100 */
}
Bug#985268: ITP: golang-github-huandu-go-sqlbuilder -- A flexible and powerful SQL string builder library plus a zero-config ORM.
Package: wnpp
Severity: wishlist
Owner: deb...@thola.io
* Package name: golang-github-huandu-go-sqlbuilder
Version : 1.12.0-1
Upstream Author : Huan Du
* URL : https://github.com/huandu/go-sqlbuilder
* License : Expat
Programming Lang: Go
Description : A flexible and powerful SQL string builder library plus a
zero-config ORM.
SQL builder for Go Go (https://github.com/huandu/go-sqlbuilder/actions)
GoDoc (https://pkg.go.dev/github.com/huandu/go-sqlbuilder) Go Report
(https://goreportcard.com/report/github.com/huandu/go-sqlbuilder) Coverage
Status (https://coveralls.io/github/huandu/go-sqlbuilder?branch=master)
• Install (#install)• Usage (#usage) • Basic
usage (#basic-usage)• Pre-defined SQL builders
(#pre-defined-sql-builders)• Build SQL for MySQL, PostgreSQL or
SQLite (#build-sql-for-mysql--postgresql-or-sqlite)• Using Struct
as a light weight ORM (#using--struct--as-a-light-weight-orm)•
Nested SQL (#nested-sql)• Use sql.Named in a builder
(#use--sqlnamed--in-a-builder)• Argument modifiers
(#argument-modifiers)• Freestyle builder (#freestyle-builder)• Using
special syntax to build SQL (#using-special-syntax-to-build-sql)•
Interpolate args in the sql (#interpolate--args--in-the--sql-)• FAQ
(#faq) • What's the difference between this package and squirrel
(#what-s-the-difference-between-this-package-and--squirrel-)• License
(#license) Package sqlbuilder provides a set of flexible and powerful
SQL string builders. The only goal of this package is to build SQL
string with arguments which can be used in DB#Query or DB#Exec defined
in package database/sql. Install Use go get to install this package.
.
shell go get github.com/huandu/go-sqlbuilder
.
UsageBasic usage We can build a SQL really quick with this package.
.
```go sql := sqlbuilder.Select("id", "name").From("demo.user").
Where("status = 1").Limit(10). String()
.
fmt.Println(sql)
.
// Output: // SELECT id, name FROM demo.user WHERE status = 1 LIMIT 10 ```
.
In the most cases, we need to escape all input from user. In this case,
create a builder before starting.
.
```go sb := sqlbuilder.NewSelectBuilder()
.
sb.Select("id", "name", sb.As("COUNT(*)", "c")) sb.From("user")
sb.Where(sb.In("status", 1, 2, 5))
.
sql, args := sb.Build() fmt.Println(sql) fmt.Println(args)
.
// Output: // SELECT id, name, COUNT(*) AS c FROM user WHERE
status IN (?, ?, ?) // [1 2 5] ``` Pre-defined SQL builders
Following builders are implemented right now. API document
and examples are provided in the godoc document. • Struct
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Struct):
Builder factory for a struct.• CreateTableBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#CreateTableBuilder):
Builder for CREATE TABLE.• SelectBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#SelectBuilder):
Builder for SELECT.• InsertBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#InsertBuilder):
Builder for INSERT.• UpdateBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#UpdateBuilder):
Builder for UPDATE.• DeleteBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#DeleteBuilder):
Builder for DELETE.• UnionBuilder
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#UnionBuilder):
Builder for UNION and UNION ALL.• Buildf
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Buildf):
Freestyle builder using fmt.Sprintf-like syntax.• Build
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Build): Advanced
freestyle builder using special syntax defined in Args#Compile
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#Args.Compile).•
BuildNamed
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#BuildNamed): Advanced
freestyle builder using ${key} to refer the value of a map by key.
There is a method SQL(sql string) implemented by all statement builders
like SelectBuilder. We can use this method to insert any arbitrary SQL
fragment when building a SQL. It's quite useful to build SQL containing
non-standard syntax supported by a OLTP or OLAP system.
.
``go // Build a SQL to create a HIVE table. sql :=
sqlbuilder.CreateTable("users").
SQL("PARTITION BY (year)"). SQL("AS"). SQL(
sqlbuilder.Select("columns[0] id", "columns[1] name", "columns[2]
year").
From("all-users.csv`"). Limit(100). String(),
). String()
.
fmt.Println(sql)
.
// Output: // CREATE TABLE users PARTITION BY (year) AS SELECT columns[0]
id, columns[1] name, columns[2] year FROM all-users.csv LIMIT 100 ```
.
To learn how to use builders, check out examples on GoDoc
(https://pkg.go.dev/github.com/huandu/go-sqlbuilder#pkg-examples).
Build SQL for MySQL, PostgreSQL or SQLite Parameter markers are different
in MySQL, PostgreSQL and SQLite. This package provides some methods to
set the type of markers (we call it "flavor") in all builders.
.
By default, all builders uses DefaultFlavor to build SQL. The defaul
Bug#985272: ITP: golang-github-huandu-go-assert -- Magic assert macros for Go.
Package: wnpp
Severity: wishlist
Owner: deb...@thola.io
* Package name: golang-github-huandu-go-assert
Version : 1.1.5-1
Upstream Author : Huan Du
* URL : https://github.com/huandu/go-assert
* License : Expat
Programming Lang: Go
Description : Magic assert macros for Go.
Package assert - Magic assert macros for Go Go Go Doc
(https://pkg.go.dev/github.com/huandu/go-assert)
.
Package assert provides developer a way to assert expression and output
useful contextual information automatically when a case fails. With this
package, we can focus on writing test code without worrying about how
to print lots of verbose debug information for debug.
.
Here is a quick sample.
.
```go import "github.com/huandu/go-assert"
.
func TestSomething(t *testing.T) {
str := Foo(42) assert.Assert(t, str == "expected")
// This case fails with following message. // // Assertion failed:
// str == "expected" // Referenced variables are assigned
in following statements: // str := Foo(42)
.
} ``` Import Use go get to install this package.
.
shell go get github.com/huandu/go-assert
.
.
Current stable version is v1.*. Old versions tagged by v0.* are obsoleted.
UsageAssertion methods If we just want to use functions like Assert,
Equal or NotEqual, it's recommended to import this package as ..
.
```go import "github.com/huandu/go-assert"
.
func TestSomething(t *testing.T) {
a, b := 1, 2 assert.Assert(t, a > b)
// This case fails with message: // Assertion failed: // a > b
.
}
.
func TestAssertEquality(t *testing.T) {
assert.Equal(t, map[string]int{
"foo": 1, "bar": -2,
}, map[string]int{
"bar": -2, "foo": 1,
})
// This case fails with message: // Assertion failed: // The
value of following expression should equal. // [1] map[string]int{
// "foo": 1, // "bar": -2, // } // [2]
map[string]int{ // "bar": -2, // "foo": 1, //
} // Values: // [1] -> (map[string]int)map[bar:-2 foo:1] //
[2] -> (map[string]int)map[bar:-2 foo:1]
.
} ``` Advanced assertion wrapper: type A If we want more controls on
assertion, it's recommended to wrap t in an A.
.
There are lots of useful assert methods implemented in A. • Assert
(https://godoc.org/github.com/huandu/go-assert#A.Assert)/Eqaul
(https://godoc.org/github.com/huandu/go-assert#A.Equal)/NotEqual
(https://godoc.org/github.com/huandu/go-assert#A.NotEqual):
Basic assertion methods.• NilError
(https://godoc.org/github.com/huandu/go-assert#A.NilError)/NonNilError
(https://godoc.org/github.com/huandu/go-assert#A.NonNilError):
Test if a func/method returns expected error.• Use
(https://godoc.org/github.com/huandu/go-assert#A.Use): Track variables. If
any assert method fails, all variables tracked by A and related in assert
method will be printed out automatically in assertion message. Here is
a sample to demonstrate how to use A#Use to print related variables in
assertion message.
.
```go import "github.com/huandu/go-assert"
.
func TestSomething(t *testing.T) {
a := assert.New(t) v1 := 123 v2 := []string{"wrong", "right"} v3 :=
v2[0] v4 := "not related" a.Use(&v1, &v2, &v3, &v4)
a.Assert(v1 == 123 && v3 == "right")
.
// This case fails with following message. // // Assertion failed:
// v1 == 123 && v3 == "right" // Referenced variables are
assigned in following statements: // v1 := 123 // v3 :=
v2[0] // Related variables: // v1 -> (int)123 // v2 ->
([]string)[wrong right] // v3 -> (string)wrong
.
}
Re: Bug#1026087: ITP: distribution-gpg-keys -- GPG keys by various Linux distributions
Hi! On Thu, Dec 15, 2022 at 03:12:21PM +0100, Guillem Jover wrote: > The project name talks about gpg keys, but those are really OpenPGP > keys (or even better, certificates). I've asked upstream to rename the > project to avoid this common confusion. So you might want to wait until > that's settled to avoid multiple trips over NEW. > > <https://github.com/xsuchy/distribution-gpg-keys/issues/76> Thank you very much! I liked this issue on github and waiting for upstream reply. > > (If this project is also intended to only cover RPM-based distributions, > as Adam brought up, you might want to further ask them to make that clear > from the project name, say rpm-distribution-openpgp-keys or similar. But > in any case regardless of the intended target use, it still seems like a > very generic name which can be easily confused for a package that would > be needed for Debian, or derivatives.) Mainly for mock we just need keys for rpm-based distributions/repositories. On the other way we have extrepo-offline-data package where are repository keys for 3rd party debian repositories. Also maybe it's better to have extern PGP keys on one place. What do you think about it? Best Regards, Juri Grabowski
Bug#853961: general: Add single click option to XFCE file picker
Package: general Severity: wishlist On XFCE, despite having single click to open elsewhere, there is no option to single click folders to select them, would be very nice if this were changed -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: db.debian.org (and related infrastructure) updates
On ke, 2007-01-03 at 13:47 -0500, Kevin Mark wrote: > I have yet to see a use case for this LDAP item. Is it strictly for a > male/femaie survey that other FLOSS projects will join? Does this mean > that people who dont self-identify as male or female are just not > counted? According to some stats that could be 100 people. Is there any > ISO standard that is inclusive of those uncounted people? You have reached the Debian Oracle. Please allow the Oracle to translate Steve's message to plain English. Steve is a great guy, but he occasionally uses difficult words and constructs of grammar, and those can sometimes confuse the rest of us. He is the victim of a childhood spent in a Catholic orphanage run by Latin-speaking priests, so he grew up thinking "alea iacta est" was a normal way of saying "yes, sir, I will fix a release critical bug at once, sir, thank you sir". The key phrase in Steve's verbiage is "I think we'll be able to make do with an opt-in binary gender classification". "I think" is a pair of words that is often used to indicate personal opinion, so Steve uses it to say that what he says next is what the project should do as far as he is concerned, but that it isn't official Debian policy. "Make do" is another important word pair, which means "manage to suffer without excessive or undue pain". Here Steve indicates that although the solution chosen is not perfect, it is good enough at least for now, and gives the implication that we have more important things to worry about. The third really significant part is "opt-in binary gender classification". "Binary gender classification" is Steve's Latinesque way of saying "there are two genders to choose from". In this case, there's two choices; by implication, they are "male" and "female" rather than "C" and "C++". With "opt-in" Steve means that Debian developers may opt, er, in, into telling everyone whether they're male or female. That means they can do it if they want to, or not do it if they don't want to. In some cases, if the other available choices are inappropriate for them, the might not be able to fill it in, but "opt-in" covers that, too. So those who want to, and are able to, to choose from the two gender options can do so, and everyone else can choose neither. So actually there are three values: male, female, and unspecified. This should cover the central part of your message: people who do not identify themselves as "male" or "female" can choose "unspecified". >From a vast experience in dealing with humankind, the Debian Oracle further provides the following statements to further respond to your question: The use case for this field is purely statistical, but it is in no way tied to any existing or planned FLOSS surveys or other projects than Debian. The ISO does not have a non-binary gender classification system that Debian could use. If we want to make the statistics classify every person's gender exactly, the field needs to be free-form text. I hope that this explains everything, Kev. You owe the Oracle an e-mail quotation trimming device. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Creation of custom "configured" packages?
Hi, in case I am in the wrong list, I beg you pardon, but I asked this already in debian-user without success. I would like to build customized, configured packages (for example additional bash script for the bash package, some default keybindings for screen, some host in /etc/ssh/known_hosts for ssh ... the list is endless), because maitainigs multiple systems becomes frustrating otherwise, if you maintain more than 2 computers (4 in my case). What would be the best (cleanest, most debian-like solution) be? I thought of "meta-packages" with pre-depends to the real packages and dpkg-divertions for the config files? Are there other possibilities? dpsyco does not seem to do what I want, at least not enough of what I want (though I must admin, I didn't read the whole documentation yet). Are there other packages like dpsyco, which could help? Thank you very much in advance. W. la Tendresse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Creation of custom
Am 15.05.2006 um 10:32 Uhr haben Sie geschrieben: > On Mon, May 15, 2006 at 09:49:00AM +0200, [EMAIL PROTECTED] wrote: [...snip...] > > Custom *packages* is probably more on-topic for debian-mentors, but I don't > think that custom packages are the right solution. > Sorry for that. > > What would be the best (cleanest, most debian-like solution) be? I > > thought of "meta-packages" with pre-depends to the real packages and > > dpkg-divertions for the config files? > > I don't think you can dpkg-divert conffiles, which makes it a bit tricky to > do that anyway. > Well thanks, did not know that! Then my "solution" does not seen to make sense. > The correct solution to your problem, I think, is a system management > application such as CFEngine or (my preferred option) Puppet. These systems > allow you to specify rules which describe how your system is supposed to > look, and then the program does what's needed to make that happen. You can > make classes, too, which are generic configuration fragments which you can > apply to a group of hosts -- a very powerful feature which allows you to > make the common config parts really common. > Sound ver good. I already headre about CFEngine, don't know puppet yet. Will have a look at both og them. > CFEngine is in Debian, but has some real nasty frustrations. Puppet isn't > in Debian, but Jamie is working hard on the packages and I've got some > provisional ones built from his sources if you want to try it out. Puppet > is fairly new on the scene, but is maturing fast, and has much less > irritations. > > - Matt > Well, of course I would like to try, that's why I asked ;-) So how can I get my (virtual) fingers on that (puppy) packages? Are they for sarge, otherwiese I will (have to) build some myself. What is the URL for puppy? Thanks. W. la Tendresse -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Virus intercepted
A message you sent to <[EMAIL PROTECTED]> contained Worm.SomeFool.P and has not been delivered. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Introducing myself
Hello everyone, I'm an Italian undergraduate student of Informatics in Trento. I love Debian and I've used it from a lot of years. I've also invited and helped my friends to use it. This year I would like to do something that is useful for the Debian project and for me, so I'm very interested in participating in Google Code of Summer. I mainly program in Java, however I have also some skills in C and I can learn other languages. I've seen that Debian participated in GCoS last year, so I hope that it will participate also this year. Is this mailing-list the right place to start a collaboration? Thanks in advance for any reply. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bugs in default GNOME etch?
On su, 2007-01-21 at 13:38 +0100, Yves-Alexis Perez wrote:
> On dim, 2007-01-21 at 12:31 +, Stephen Gran wrote:
> > This could quickly get recursive. Let me save you the trouble:
> >
> > while true; do
> > echo "kool-aid drinker: it's easier to find an item in a short menu"
> > | \
> > mail -s "Re: Bugs in default GNOME etch?"
> > [EMAIL PROTECTED]
> > echo "everyone else: it's impossible to find an item that isn't
> > there" | \
> > mail -s "Re: Bugs in default GNOME etch?"
> > [EMAIL PROTECTED]
> > done
> >
>
> This one isn't really recursive.
The Debian Oracle has detected an implicit question!
Loops are, in fact, recursion! More importantly, they are an optimized
version of tail recursion. The loop above could be written as:
debian_discussion_about_gnome_menus()
{
echo "kool-aid drinker: it's easier to find an item in a short menu" |
mail -s "Re: Bugs in default GNOME etch?" [EMAIL PROTECTED]
echo "everyone else: it's impossible to find an item that isn't there" |
mail -s "Re: Bugs in default GNOME etch?" [EMAIL PROTECTED]
debian_discussion_about_gnome-menus
}
In fact, if you use an implementation of your preferred language that
does not optimize tail recursion stack usage, you have a better
simulation of the Debian discussions: eventually the stack will
overflow, and the discussion will end. In real life, Debian discussions
also eventually end, for example when all participants on one side of
the debate graduate from school and no longer have extra free time.
Nifty!
Because the Debian Oracle is in an especially good mood today, you get
an extra answer: the correct, and traditional solution method to the
Dilemma About GNOME Menus in Debian is to make it possible to have
either the GNOME-style menus (short, nothing unnecessary) or the
Debian-style ones (huge, everything is in there, sometimes multiple
times). Everyone can be happy!
You owe the Oracle a pair of snow shoes, a shovel, warm gloves, and a
hair-dryer.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#413735: ITP: mdk2 -- Destructive 802.11 wireless network hacking tool
On ti, 2007-03-06 at 15:31 -0600, Ron Johnson wrote: > > mdk2 is a tool designed to crash 802.11 wireless network. ... > What's the non-black hat purpose of this tool? The Debian Oracle is glad you asked! This is an important fashion question: what headware should one ask when using each Debian package. Any confusion about this issue can cause severe embarrassment, such as excessive quoting. There is excessive literature on other items of apparel for each Debian package. The Left-Sock-Color and Glove-Material package headers alone are worth their weight in gold (assuming a standard weight bit). For hats, the two most common styles are the American baseball cap, possibly adorned with a chicken logo, or the construction site "hard hat" helmet, in honor of all the hard work that goes into each Debian package. For this package in particular, since it is meant for testing the security and robustness of wireless networks, a hair net would be the obvious, though daring choice. Hair nets can be found in many materials and colors, from pink rubber to green leather and beyond. The classics, such as clear nailon, are of course always a good choice. You owe the Debian Oracle a patch to icedove to warn about quoting more than you write yourself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux/Debian documentation suggestion
On ke, 2007-04-18 at 14:31 -0500, Steve Greenland wrote: > apt-file (0.2.0-1) unstable; urgency=low > > * Initial Release. > > -- Sebastien J. Gross <[EMAIL PROTECTED]> Sat, 13 Oct 2001 21:36:47 +0200 > > I've been living without this for 5+ years!?! How come no one told me > about this? The Debian Oracle is mighty glad you asked that question! It's about time someone did. The tale of how the existence of apt-file was suppressed from the Debian developer community is one of the more sordid and shameful ones in Debian. It has all the scandalous ingredients of the decline of the Roman empire. Unfortunately, it cannot be told. The discussion involved happened on debian-private, and its participants have said they don't want it published. Not even the Debian Oracle is mighty enough to survive the punishment for revealing what happens on -private. Oops. You owe the Debian Oracle safe haven and a black anti-helicopter missile launcher. Now, please. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: Why no Opera?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roberto C. Sánchez wrote: > For that, you will have to ask the ftp masters and the security team. I > am not in a position to speak to their official stance in terms of what > requirements they might have for software like opera to be in Debian and > the Debian Policy manual does not enumerate them either. The security team gives no support for contrib and non-free packages[1]. > > Regards, > > -Roberto > [1] http://www.debian.org/security/faq#contrib -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG//EUYy49rUbZzloRAo26AJoDnUVE4RM1TrxytaaqfVTULuk5/wCeLgzr bcNcW7F/4f4Fqkj0QG5Rg+8= =hobb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#613211: RFP: libmoosex-types-portnumber -- IANA port number type library for Moose
Package: wnpp Severity: wishlist * Package name: libmoosex-types-portnumber Version : 0.02 Upstream Author : Thiago Rondon * URL or Web page : http://search.cpan.org/~tbr/MooseX-Types-PortNumber-0.02/ * License : Artistic or GPL-1+ Description : IANA port number type library for Moose Almost perfect CPAN Testers reports, no open bug in RT, code is sane. Copyright and license information seems clear enough to me in the source. Bye, -- intrigeri -- 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/851v3couju@boum.org
Bug#613213: RFP: libmoosex-types-netaddr-ip -- NetAddr::IP related types and coercions library for Moose
Package: wnpp Severity: wishlist * Package name: libmoosex-types-netaddr-ip Version : 0.04 Upstream Author : Todd Caine * URL or Web page : http://search.cpan.org/~tcaine/MooseX-Types-NetAddr-IP-0.04/ * License : Same as Perl 5.10.1 or, at your option, any later version of Perl 5 you may have available. Description : NetAddr::IP related types and coercions library for Moose No open bug in RT, code is sane, almost perfect CPAN Testers reports. Every dependency is in Debian already. Bye, -- intrigeri -- 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/85vd0onfsl@boum.org
Re: A case study of a new user turned off debian
On 06 Nov 2003 01:06:25 -0500, Greg Stark <[EMAIL PROTECTED]> posted to debian-devel: > Personally I'm of the opinion that stable is useless. It certainly > has no use for me. Perhaps if I ran a production server on debian I > might think otherwise but I rather doubt it. When I had production > servers they all ran 2.4 and needed the latest stable releases of > anything important like database, mail, web server services. > If I ran production servers on debian today I would probably pick > an arbitrary date off snapshot.debian.org and declare that my > "stable". If I had security problems I would pick a date recent > enough to have the security fixes, test it, and declare it > "stable". > It wouldn't be guaranteed to be bug-free, but then nothing is. > Stable has tons of minor bugs that no upstream maintainer would > listen to because they were fixed aeons ago anyways, or more likely > are no longer relevant in current sources. Sounds more like a case of "stable plus backports of the important pieces". Now if only somebody were telling me where to find "stable" backports for Woody of the packages I need ... (Probably I'm too much of a skeptic for not believing that a random hit in the search engine at apt-get.org is what I should be using.) /* era */ -- formail -s procmail <http://www.iki.fi/era/spam/ >http://www.euro.cauce.org/ cat | more | cat<http://www.iki.fi/era/unix/award.html>http://www.debian.org/
subscribe
subscribe
Re: /usr/dict/ -> /usr/share/dict/ request (bug #110632)
David Coe wrote: > > Hi all, > > A user has filed a wishlist bug against (potato) wenglish because the > (slink) symlink from /usr/dict/words is now a symlink from > /usr/share/dict/words, per FHS. This user would like /usr/dict/words > reinstated as a symlink to the user's preferred word list. > > He claims, not unreasonably, that old scripts and users expect > to find /usr/dict/words. The only link I would allow is /usr/dict --> /usr/share/dict, but that can be done easily by the system maintainer in a system with such scripts or such problems, that should be the exception. We can be polite about that, but is not so big a problem. There is other problem about that, what package should be the owner of that link? Currently there is no common package for all dicts, and setting it from base files seems to me quite heavy. From the dictionaries-common project, dictionaries-common package should be the natural owner if that link is set, but from the current situation I find no good package to have the transition link. Agustin, -- = Agustín Martín Domingo, Dpto. de Física, ETS Arquitectura Madrid, (U. Politécnica de Madrid) tel: +34 91-336-6536, Fax: +34 91-336-6554, email:[EMAIL PROTECTED], http://corbu.aq.upm.es/~agmartin/welcome.html
ͨÓÃÍøÖ·(¿ì½ÝÍøÖ·¡¢ÍøÂçʵÃû)------ÍøÂçµØÖ·ÐÂÐÎÏó
尊敬的客户： 通用网址(快捷网址、网络实名)――网络地址新形象 直接输入企业、产品、网站的名称，即可直达目标网站 无需记忆复杂的域名、网址， 无需 http://、www 、 .com、.net等前后缀，是继IP、域名之后，最先进、最快捷、 最方便的第三代互联网访问标准 。 允许个人注册，开放通用词汇注册并可自由转让，商机无限！ 通用网址带来更多访客与商机 1、客户无需死记硬背复杂的域名/网址，凭着简单的记忆、在浏览器地址栏输入印象 中的名字，即可找到您。 2、不必注册所有的顶级域名，降低企业经营成本！ 严格的服务选择原则，保护公司 商标权和全球性、区域性识别！ 3、当输入名不精确时，智能推测功能仍可帮客户找到您。 4、利用多样的词汇和特殊的符号增强品牌的可识别性！ 5、可指向深层链接地址，便于网站深层次内容被直接访问！ 更多介绍，敬请访问： 知识商务在线：www.21kbol.com 通用网址：http://www.21kbol.com/web-keywords.htm 现在注册：http://203.196.7.89/client/xuxk/realname_1.html 注：本邮件为善意的商业邮件，如有打扰敬请删除!!
Bug#111764: general: Apache-perl installs in 5.6.0 dir instead of 5.6.1
Package: general Version: 20010909 Severity: grave -- System Information Debian Release: testing/unstable Kernel Version: Linux tarjei 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i586 unknown The error is as following: I installed the apachepackage as normal. Then when I tried to install apache-perl, I get thr error rs: Here is the full output of the process: tarjei:/etc/ldap# apt-get install apache-perl Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: libdevel-symdump-perl The following packages will be REMOVED: apache The following NEW packages will be installed: apache-perl libdevel-symdump-perl 0 packages upgraded, 2 newly installed, 1 to remove and 1 not upgraded. Need to get 756kB of archives. After unpacking 922kB will be used. Do you want to continue? [Y/n] y Get:1 ftp://ftp.se.debian.org woody/main libdevel-symdump-perl 2.00-5 [13.5kB] Get:2 ftp://ftp.se.debian.org woody/main apache-perl 1.3.19-1-1.25-4 [742kB] Fetched 756kB in 25s (29.6kB/s) (Reading database ... 31427 files and directories currently installed.) Removing apache ... Stopping web server: apache. /usr/sbin/apachectl stop: httpd stopped dpkg - warning: while removing apache, directory `/var/log/apache' not empty so not removed. dpkg - warning: while removing apache, directory `/etc/apache' not empty so not removed. Selecting previously deselected package libdevel-symdump-perl. (Reading database ... 31392 files and directories currently installed.) Unpacking libdevel-symdump-perl (from .../libdevel-symdump-perl_2.00-5_all.deb) ... Selecting previously deselected package apache-perl. Unpacking apache-perl (from .../apache-perl_1.3.19-1-1.25-4_i386.deb) ... Setting up libdevel-symdump-perl (2.00-5) ... Setting up apache-perl (1.3.19-1-1.25-4) ... Initializing apache config for immediate operation. Reloading apache modules. [Sun Sep 9 12:59:07 2001] [error] Can't locate Apache.pm in @INC (@INC contains: /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/ /etc/apache/lib/perl) at (eval 1) line 3. /usr/sbin/apachectl start: httpd could not be started tarjei:/etc/ldap# updatedb tarjei:/etc/ldap# locate Apache.pm /usr/lib/perl/5.6.0/Apache.pm /usr/lib/perl/5.6.0/Bundle/Apache.pm /usr/share/perl/5.6.1/CGI/Apache.pm tarjei:/etc/ldap# ../init.d/apache start Starting web server: apache. [Sun Sep 9 13:04:47 2001] [error] Can't locate Apache.pm in @INC (@INC contains: /usr/local/lib/perl/5.6.1 /usr/local/share/perl/5.6.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.6.1 /usr/share/perl/5.6.1 /usr/local/lib/site_perl /usr/lib/perl5/5.6 /usr/lib/perl5/5.005 . /etc/apache/ /etc/apache/lib/perl) at (eval 1) line 3. Tarjei(email: [EMAIL PROTECTED]):
Bug#706068: ITP: SQL Workbench/J -- A free, DBMS-independent, cross-platform SQL tool
Package: wnpp Severity: wishlist * Package name: sqlworkbenchj Version : 114 Upstream Author : Thomas Kellerer * URL : http://www.sql-workbench.net * License : Apache License, Version 2.0 Programming Lang: Java Description : A free, DBMS-independent, cross-platform SQL tool SQL Workbench/J was recently licensed as Apache 2.0, and is a fantastic and versatile tool for working with SQL databases. Features: - Display result data from SQL queries (Screenshot) - Edit, insert and delete data directly in the result table (Screenshot) - Powerful export command to write text files (aka "CSV"), XML, HTML or SQL (including BLOB data). - All user tables can be exported into a directory with a single command. Export files can be compressed "on-the-fly". - Powerful text and XML file import. A set of files (including compressed files) can be imported from a directory with a single command. Foreign key constraints are detected to insert the data in the correct order - Compare two database schemas for differences. The XML output can be transformed into the approriate SQL ALTER statements using XSLT - Compare the data of two database and generate the necessary SQL statements to migrate one to the other. - Reformatting (Pretty-Print) of SQL Statements (Screenshot) - Full support for BLOB data in query results, SQL statements, export and import. Read more... - Select rows from related tables according to their foreign key definitions (Screenshot1 Screenshot2). - Search text in procedure, view and other sources using a SQL command or a GUI (Screenshot) - Search for data across all columns in all tables using a SQL command or a GUI (Screenshot) - Copy data directly between to database servers using a SQL command or a GUI (Screenshot) - Macros (aka aliases) for frequently used SQL statements - Variable substitution in SQL statements including smart prompting for values (can be combined with macros) - Auto completion for tables and columns in SQL statements (Screenshot) - Tooltips for INSERT statements to show the corresponding value or column (Screenshot) - All SQL Scripts (including Workbench specific commands) can be run in batch mode - An interactive console mode (Screenshot) - Display database objects and their definitions (Screenshot) - Display table source (Screenshot) - Display view, procedure and trigger source code (Screenshot) - Display foreign key constraints between tables (Screenshot) - SQLWorkbench/J is free ( published under the Apache 2.0 license) -- 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/20130424105838.c229eba0...@foetus.synth.no
Bug#626380: ITP: onioncat -- IP-Transparent Tor Hidden Service Connector
Package: wnpp Owner: intrigeri+deb...@boum.org Severity: wishlist * Package name: onioncat Version : 0.2.2 Upstream Author : Bernhard R. Fischer * URL or Web page : http://www.cypherpunk.at/onioncat/ * License : GPL-3 Description : IP-Transparent Tor Hidden Service Connector OnionCat creates a transparent IP layer on top of Tor's hidden services. It transmits any kind of IP-based data transparently through the Tor network on a location hidden basis. You can think of it as a point-to-multipoint VPN between hidden services. OnionCat is a stand-alone application which runs in userland and is a connector between Tor and the local OS. Any protocol which is based on IP can be transmitted. Of course, UDP and TCP (and probably ICMP) are the most important ones but all other protocols can also be forwarded through it. OnionCat is based on IPv6 but the since version 0.1.9 also IPv4 packets are forwarded. In any case the local OS must support IPv6. See OnionCat and IPv4 for configuration of IPv4 transport. OnionCat now also supports TAP devices for bridging virtual machines and it supports IPv6 routing. I am in the process of updating and cleaning up the packaging debian/ directory shipped in upstream SVN, aiming at putting the package in good shape so that it can be uploaded into the Debian archive. I intend to maintain this package in collab-maint to start with. Bye, -- intrigeri -- 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/858vudfkrh@boum.org
Bug#636041: ITP: libgsecuredelete -- wrapper library for the secure-delete tools
Package: wnpp Owner: intrigeri+deb...@boum.org Severity: wishlist * Package name: libgsecuredelete Version : 0.1 Upstream Author : Colomban Wendling * URL or Web page : http://wipetools.tuxfamily.org/libgsecuredelete.html * License : GPL-3+ Description : wrapper library for the secure-delete tools GSecureDelete is a GObject wrapper library for the secure-delete tools (srm, sfill, sswap and smem), aiming to ease use of these tool from programs by providing a simple but complete API to invoke them. Packaging repository: gbp-clone git://webmasters.boum.org/libgsecuredelete Bye, -- intrigeri -- 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/857h6zq4w6@boum.org
Bug#636043: ITP: nautilus-wipe -- Secure deletion extension for Nautilus
Package: wnpp Owner: intrigeri+deb...@boum.org Severity: wishlist * Package name: nautilus-wipe Version : 0.1 Upstream Author : Colomban Wendling * URL or Web page : http://wipetools.tuxfamily.org/nautilus-wipe.html * License : GPL-3+ Description : Secure deletion extension for Nautilus Nautilus Wipe is a Nautilus extension that adds "Securely erase" and "Securely fill empty space" items to the right-click menu. . The progress and results of the operations are shown in a progress dialog. Packaging repository: gbp-clone git://webmasters.boum.org/nautiluswipe Note that nautilus-wipe depends on libgsecuredelete, which just had its own ITP filed. Bye, -- intrigeri -- 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/851ux7q4rd@boum.org
Bug#638504: ITP: mat -- Metadata anonymising toolkit
Package: wnpp Owner: intrigeri+deb...@boum.org Severity: wishlist * Package name: mat Version : 0.1 Upstream Author : Julien Voisin * URL or Web page : https://gitweb.torproject.org/user/jvoisin/mat.git * License : GPL-2 Description : Metadata anonymising toolkit Metadata consist of information that characterizes data. Metadata are used to provide documentation for data products. In essence, metadata answer who, what, when, where, why, and how about every facet of the data that are being documented. . Metadata within a file can tell a lot about you. Cameras record data about when a picture was taken and what camera was used. Office documents like pdf or Office automatically adds author and company information to documents and spreadsheets. . Maybe you don't want to disclose those information on the web. . Mat only remove metadata from your files, it does not anonymise their content, nor it can handle watermarking, steganography, or any too custom metadata field/system. . If you really want to be anonym, use format that does not contain any metadata, or better: use plain-text. -- intrigeri -- 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/85ty9dmnx1@boum.org
Recommending packages not available in arch
hi all, recently on IRC, i asked why "to exclude specific archs in Recommends/Suggests?". the use case is, that some package "foo" might not be available for a specific arch (e.g. FTBFS on hurd-any), and package "bar" would still like to recommend it (since "bar" is used together with "foo" 'in all but unusual installations' - and hurd-any is considered an 'unusual' though possible environment, 'unusual' mainly because "bar" is not available, and also because it's hurd...). my intuition tells me to use "Recommends: foo", and everyone can use "bar" and will be happy (though the hurd-people less so, because they don't get the extra features that 'foo' provides until somebody fixes that FTBFS). however, one of the first answers i got was: "recommending a non-existent package is forbidden". now §2.2.1 of our policy indeed says that 'packages in main must not require or recommend a package outside of main for compilation or execution (thus, the package must not declare a "Pre-Depends", "Depends", "Recommends" [...] relationship on a non-main package)'. my first reaction was that the intention of this paragraph is mainly to keep the system uncontaminated from non-free and contrib, but while the §2.2.1 refers a lot to DFSG, the quote above is explicitely "in addition" to the DFSG, so it *might* apply. so my question is: Does §2.2.1 indeed apply to Recommends for packages that are in the main archive but not available for a given architecture? If so, what is the reasoning? Also: does the "main archive" contain multiple architectures, or do we have a main archive per architecture? (if the former, then i think that §2.2.1 does not apply). mgfsadr IOhannes signature.asc Description: OpenPGP digital signature
PHP modules only for PHP 7.3 in buster
Hi, I am deeply sorry if I'm on the wrong list. I am not a newcomer to Debian, but I didn't take the time to dig in all the lists and processes. Recently, I saw some PHP modules that hit testing and were only compiled against PHP 7.3: - php-apcu (#911719) - php-igbinary (#911670) - php-redis (#913357) - php-mailparse As the maintainer as said (in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911670#10), it seems that we are in the middle of a transition. However, the main php package is still depending on php 7.2 : in the meantime, a lot of module, and applications are completely broken. Moreover, php7.0 and php7.2 are still available in buster, and it seems that it's currently impossible to use those PHP versions with the above modules. As far as I know, some applications are not able to run on PHP 7.3, so supporting PHP 7.2 in buster could be a good idea. I also find cumbersome to launch "apt-mark hold php-" for now, waiting for an explanation or a resolution. So my main question is: what is the plan for PHP modules? Have a nice day, Adrien
Re: Debian CI pipeline for Developers
On 11/16/18 3:14 PM, Kentaro Hayashi wrote: > package repository, sure we can change the project's setting, but > debian/.gitlab-ci.yml seems to be the proper default setting. i don't think there is any reason to use a (hidden) dotfile in the debian/ directory. the default uses a dotfile in order to not clutter the root directory of the repository, at least visually (ignoring the fact that the dotfiles are still pretty much visibly and having the configuration for all those various CI-services in your root - .gitlab-yi.yml, .travis.yml, appveyor.yml and what - not is *quite* a clutter). so if you put the file in the debian/ directory anyhow, i'd just pick a sensible and visible name, like "debian/salsa-ci.yml" gfamdsr IOhannes signature.asc Description: OpenPGP digital signature
call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)
On 04.12.18 19:28, IOhannes m zmoelnig wrote: > Package: wnpp > * Package name: pd-csound > Version : 1.01.0 > > pd-csound used to be built from the csound (source) package, but upstream has > factored it out into a separate project (starting with fresh version numbers). > This is an attempt to bring the package back in. stretch features a pd-csound binary package built from "csound" with a version number "1:6.08.0~dfsg-1". upstream has factored out this component into a separate project (and therefore pd-csound is currently no more in buster), starting with a new version (1.01.0). as mandated by the policy, i'd like to discuss, whether an epoch bump for the new source package "pd-csound" (to be "2:1.01.0-1") is warranted, or indeed a good idea. the first version of Csound in Debian seems to have been "3.484.0d-1" (according to snapshot.d.o), with pd-csound appearing at "1:5.08.0.dfsg2-1". the factored out project is relatively new, i don't know how the versions will evolve. fgmasdr IOhannes
Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)
On 12/4/18 9:34 PM, Simon McVittie wrote: > > I would suggest talking to the upstream developer of pd-csound. It seems > reasonably likely that their users will be confused by the fact that > that version 1.01.0 of the "Csound external" (I assume that's some sort > of loadable module, analogous to a Python module?) is newer/better than > version 6.08.0 of the Csound external, despite its lower version number? > > If they agree that this is confusing, they might be willing to re-version > to 7.01.0 or something, so that version numbers keep going up. > > If they are unwilling to change the version number, then bumping the > epoch seems like a correct Debian-level workaround for the version > numbering scheme having been reset. i asked upstream, and their answer is: > The version was always 1.00 even when it was inside Csound. Minor > changes made it go to 1.01 when we moved it out. It is not the same as > the Csound version. So I am not really keen on changing this. so it seems that the Debian *binary* package should have used a different version than the source package in the first place. it also gives me confidence, that the upstream version number will not increment much in the next time, which should keep us safe from re-using the same version (without epoch) gfadsmr IOhannes signature.asc Description: OpenPGP digital signature
Re: call for epoch (was Re: Bug#915553: ITP: pd-csound -- Csound external for Pure Data)
On 05.12.18 20:19, Paul Gevers wrote: > Hi, > > On 04-12-2018 20:03, IOhannes m zmölnig (Debian/GNU) wrote: >> as mandated by the policy, i'd like to discuss, whether an epoch bump >> for the new source package "pd-csound" (to be "2:1.01.0-1") is >> warranted, or indeed a good idea. > > Can at least the source package not carry the any special epoch, or is > that too confusing? > is there any advantage of this? the source package currently only builds a single binary package (and i don't expect this to change). so i think that having different version numbers for source and binary package to only add complexity to the packaging with little gain. i have already uploaded to NEW yesterday (after the discussion here seemed to indicate consensus on the epoch bump), but of course it's awaiting ftp-masters' approval, so there is still time to re-upload. fgamsdr IOhannes
Re: Cdbs Features
On 13.05.19 18:22, Sam Hartman wrote: >> "Holger" == Holger Levsen writes: > Holger> - packages using cdbs. cdbs has features dh doesnt have and > Holger> I dont think it's wrong to use cdbs. ( > > Just for my information, what are the big features cdbs has that dh does > not? > i've migrated many of my packages from cdbs to dh, but there's one feature which cdbs sports and which i miss strongly (at least: the last time i checked) in dh (so much, that i haven't converted a couple of packages): building of multiple "flavours". that is: building the same code-base multiple times, with differing configurations. while it is possible to do that with dh, it amounts to either a lot of near-duplicate lines or quite some GNU make trickery, which i'd rather not spread across multiple d/rules fgamsdr IOhannes
Re: Cdbs Features
On 14.05.19 14:35, Mo Zhou wrote: > I'm quite interested in taking a look at how cdbs deal with such case. https://salsa.debian.org/multimedia-team/snd/blob/master/debian/rules https://salsa.debian.org/multimedia-team/soundscaperenderer/blob/master/debian/rules gfmdsrt IOhannes
Re: The Difference between debcheckout and dgit and what they try to accomplish
On 17.06.19 06:53, Helmut Grohne wrote: > Whether I use apt-get source and debdiff or dgit > and git format-patch is a detail on my side. out of curiosity (and because i usually quite enjoy your patches): do you do use dgit in *your* workflow? fgmadsr IOhannes
Re: How do you cause a re-run of autopkgtests?
On 7/21/23 12:57, G. Branden Robinson wrote: Hi folks, But I see no mechanism for interacting with autopkgtests to force them to re-run due to the remedy of a defect in the test harness itself. How is this to be done? you mean, apart from clicking on the ♻ retry icon? (you probably have to be authenticated in order to even see these icons) Should some automated mechanism for achieving this be added, and if so, where? https://ci.debian.net/api/doc mgfdsar IOhannes
Re: Making Debian available - patch for webwml
On 1/29/21 1:44 PM, Holger Levsen wrote: Hi Holger, On Thu, Jan 28, 2021 at 10:53:54AM +0100, Holger Wansing wrote: FYI: a patch has been applied in the meantime, adding such hint to nearly all d.o pages, which have links to download images [eg] www.debian.org/distrib/ to make users aware of those images. very cool, thank you very much! I'm still a bit sad we call the non-free images "unofficial" instead of "non-free", but hey, todays presentation is much better than last months already! IOW: I think we should call our non-free images our official non-free images. But still, yay progress! anecdotally, i installed buster on my wife's 13 year old i686 laptop yesterday morning (trying to refurbish it as a home-schooling device). the hardware is obviously pretty old (no x86_64!), but at least that made me hope that the wifi card might work out of the box. being fully aware of this thread (and just to be on the safe side), i checked how easy it was to find a i386 netinstaller images with non-free firmware. i'm sad to say that even though there has been obvious progress on the homepage¹, i failed. to be fair, i did find i386 images including non-free, but apparently only "full installation" ISOs, that (i suspected) wouldn't fit on my already crammed USB-stick. (i've been installing Debian since 1998 or so, and I don't think I ever used anything but the netinstaller. i'd like to keep it that way) of course, once i started the installer, it turned out that non-free firmware was indeed needed for the iwlwifi. so i copied one of the two mentioned firmware files (the other one was missing, so i assumed that the two were just different versions) from my own laptop (running sid) into a firmware/ directory on the USB stick, and started a-new. this time i was not prompted to insert a disk with the missing firmware (so providing the missing firmware was obviously pretty easy), only to find that i still could not connect to my WPA2-protected WiFi. so i just grabbed an old network cable from my bag of stuff, connected my own laptop to the old one, setup internet sharing, and from then it went kind of smoothly (apart from losing connection every other time, so it took a couple of attempts until the base system had been downloaded; but that might be due to the cable, or the rusty eth connector). after a successful installation i enabled non-free, grabbed the firmware-iwlwifi package, and since then everything seems to work splendidly (module that fan, that is making weird noises). fdmsrsa IOhannes ¹ note: i think "the page" (https://get.d.o) changed again since yesterday, and i now have been able to locate i386-netinstall+non-free images (although only after searching the page for "firmware" and then go daringly 3 more appalling pages (that reminded me fondly of ftp-directories and FAQs of yore) OpenPGP_signature Description: OpenPGP digital signature
Re: Lintian and Dpkg's :any multiarch acceptor
On 11/3/21 23:34, Felix Lechner wrote: 1. Did anyone find the latest Lintian versions (2.109.0 and up) confusing as to whether the :any should be included? The material you would have encountered includes both the context offered by Lintian (the extra information after the tag) and any relevant tag descriptions. being the one who initially triggered #995981 by blindly following advice of lintian (yes i know: *never* blindly follow lintian's advise), i think i can say that i indeed found the description of the "rules-require-build-prerequisite" tag highly confusing. in general i think tag descriptions should ony use "machine-parsable advice" if the machine-parsable is meant to be used as-is, and use human language in all other cases. that is: rather than using a string like "python3:any | python3-all:any | python3-dev:any | python3-all-dev:any | dh-sequence-python3" (which looks very much like code) use someting like "the package should probably build depend on one of python3-dev:any or dh-sequence-python3 or [...]". the point i'm trying to make is not about the correctness of the advice itself, but that an explanation that looks like a code-example is probably going to be understood as such. so if the text is not to be copy and pasted into code, it shouldn't look like tit could. fmdst IOhannes OpenPGP_signature Description: OpenPGP digital signature
Bug#1005271: ITP: csound-plugins -- plugin collection for Csound
Package: wnpp Severity: wishlist Owner: IOhannes m zmölnig (Debian/GNU) X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: csound-plugins Version : 1.0.2 Upstream Author : Csound Developers * URL : https://github.com/csound/plugins * License : LGPL Programming Lang: C, C++ Csound is a sound and music synthesis system. Drawing from over 450 signal processing modules, it can be used to model virtually any synthesizer or multi-effect processor. It can work either in real-time or as a compiler. . Csound is to sound synthesis as C is to programming. . This package contains additional plugins. Upstream has split their repository, so now add-ons for the main "Csound" package have a different repo and release cycle. To not lose those plugins in Debian, packaging the new repo is required as well. I intend to maintain this under the multimedia-team umbrella, along with the other csound related packages. gfmdasr IOhannes
Re: Package uploads silently discarded: how to investigate?
On 6/27/22 03:08, Scott Kitterman wrote: On June 27, 2022 1:06:10 AM UTC, Russ Allbery wrote: Ben Finney writes: My guess is that this is something to do with an update to the signing GnuPG key expiry date. I can get into that in a different thread if needed. The trouble is, I can only guess, because there are no messages from anything in the Debian archive telling me what went wrong. My recollection is that if the signature on the upload is invalid, we intentionally delete the upload with no notice (because we have no confirmed knowledge of who to notify). It's possible that my information is dated, though That's correct. as i've wondered myself about this in the past (not for some time though, since i no longer update my keys just-in-time): would it be possible to list reasons for (silent) discards on a prominent page? (e.g. somewhere on https://ftp-master.d.o¹). i see that ftp://ftp.upload.debian.org/pub/UploadQueue/ contains a README that says: > Only known Debian developers can upload here. Uploads have to be > signed by PGP keys in the Debian keyring. Files not meeting this > criterion or files not mentioned in a .changes file will be removed > after some time. which hints at the current behaviour (but does not make it explicit). and to be honest: i think that some random file on an ftp-server is not very visible in the first place. chrome and firefox both have ditched ftp support, which reduces the options to just *browse* the ftp-directory to...what? filezilla (shudder) and ftp on the cmdline (my beard is now white enough to get homely feelings when i encounter such a thing; but really?)² gfmsar IOhannes ¹ i guess https://ftp-master.debian.org/#rejections would be a good starting place, although this currently only speaks about explicit *rejects* , and silently discards the notion of silent *discards*. ² is there some special reason to not make the UploadQueue available via https *also*? at least i haven't found a browseable link anywhere...
Bug#1020295: ITP: dh-puredata -- debhelper addon for building Pd externals
Package: wnpp Severity: wishlist Owner: IOhannes m zmölnig (Debian/GNU) X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: dh-puredata Version : 1 Upstream Author : IOhannes m zmölnig * URL : * https://salsa.debian.org/multimedia-team/pd/dh-puredata * License : GPL3+ Programming Lang: Perl Description : debhelper addon for building Pd externals This package provides the 'pd-lib-builder' Debhelper-sequence for streamlining the process of creating Debian packages of pd-lib-builder based externals for the Pure Data computer music language. I intend to maintain this under the multimedia-team umbrella, along with the other Pure Data related packages.
Re: Namespaces for Lintian Tags
On 21.11.19 10:55, Wouter Verhelst wrote: >> 1. Shortens tag names. > I do not see how that is a good thing. > > "debian-copyright-file-uses-obsolete-national-encoding" is a sentence, which > inherently makes it extremely human-readable. For a tool that is > primarily meant to validate the output of a human, this is an immensely > useful feature. to be honest, i already find myself resorting to lintian-info for an explanation of what these supposedly "extremely human-readable sentences" actually mean (and what these meanings imply) far too often. so i probably would be just as happy with new, more terse but namespaced tags. >> 3. Frees up name space (good tags are rare). i guess this is the problem, and everything that helps with it has my +1. just my 1¢. fgamsdr IOhannes
Re: Bug#958710: ITP: nss-tls -- encrypted glibc name resolving library which uses DNS-over-HTTPS (DoH)
>>> The only reason right now is because it's the name used by upstream. I >>> choose to keep the current name and mention DoH in the description to >>> help search. >>> >>> I plan to ask upstream author if they intend to support DoT in the >>> future then the name makes a little more sense. Otherwise if they can >>> change the name to nss-https or something else to avoid confusion. >> Would it make sense to resolve that with upstream before introducing this to >> Debian? It would save a trip through New and the confusion inherent in >> package name instability. Hi, I opened an issue upstream on https://github.com/dimkr/nss-tls/issues/55. I hope I am not too enthusiast! Adrien
Re: Salsa update: no more "-guest" and more
On 4/25/20 8:34 PM, Bernd Zeimetz wrote: > Hi, > > https://docs.gitlab.com/ee/security/two_factor_authentication.html > > Enforce that (if Salsa is doing that in the meantime, ignore me). i hope you don't suggest to enforce 2FA system-wide for all users of salsa. i read you original mail as a requirement to enforce 2FA for users who want to use salsa as an authentication provider for their own applications (which is fine with me) gfmadsr IOhannes signature.asc Description: OpenPGP digital signature
Bug#836163: ITP: python-bottle-cork -- authentication for the bottle web framework
Package: wnpp Severity: wishlist Owner: "IOhannes m zmölnig (Debian/GNU)" * Package name: python-bottle-cork Version : 0.12.0 Upstream Author : Federico Ceratto * URL : http://cork.firelet.net/ * License : LGPL Programming Lang: Python Description : authentication for the bottle web framework Cork provides a simple set of methods to implement Authentication and Authorization in web applications based on Bottle. . It is designed to stay out of the way and let you focus on what your application should do. I intend to maintain this package (and a few other bottle-related packages) within the Debian Python Modules Team.
Bug#836165: ITP: python-bottle-sqlite -- SQLite3 database integration for Bottle.
Package: wnpp Severity: wishlist Owner: "IOhannes m zmölnig (Debian/GNU)" * Package name: python-bottle-sqlite Version : 0.1.3 Upstream Author : Marcel Hellkamp * URL : http://bottlepy.org/docs/dev/plugins/sqlite.html * License : MIT Programming Lang: Python Description : SQLite3 database integration for Bottle. Bottle-sqlite is a plugin that integrates SQLite3 with your Bottle application. It automatically connects to a database at the beginning of a request, passes the database handle to the route callback and closes the connection afterwards. . To automatically detect routes that need a database connection, the plugin searches for route callbacks that require a db keyword argument (configurable) and skips routes that do not. This removes any overhead for routes that don’t need a database connection. I intend to maintain this package (and a few other bottle-related packages) within the Debian Python Modules Team.
Bug#836167: ITP: python-bottle-beaker -- Bottle plugin to session and caching library with WSGI Middleware
Package: wnpp Severity: wishlist Owner: "IOhannes m zmölnig (Debian/GNU)" * Package name: python-bottle-beaker Version : 0.1.3 Upstream Author : Thiago Avelino * URL : https://github.com/bottlepy/bottle-beaker * License : MIT Programming Lang: Python Description : Bottle plugin to session and caching library with WSGI Middleware beaker is a middleware for the bottle web framework, that adds session and caching management in a transparent way. For all practical use-cases, this is a dependency for projects using python-bottle-cork. I intend to maintain this package (and a few other bottle-related packages) within the Debian Python Modules Team,
Re: Bug#837805: Acknowledgement (ITP: python-can -- Controller Area Network interface module for Python)
Control: retitle -1 ITP: python-can -- Controller Area Network interface module for Python Thanks. Ooops, seems like i forgot the subject in this ITP On Wed, Sep 14, 2016 at 08:09:05PM +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > debian-pyt...@lists.debian.org, debian-devel@lists.debian.org > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > w...@debian.org > IOhannes m zmölnig (Debian/GNU) > > If you wish to submit further information on this problem, please > send it to 837...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 837805: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837805 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Re: Bug#849154: ITP: xattrvi -- easily view and edit extended filesystem attributes in user-namespace
> * URL : https://github.com/cherti/mailexporter The correct URL seems to be https://github.com/cherti/xattrvi Interesting piece of software though. Adrien
Re: Converting to dgit
On 01/04/2017 05:42 AM, Colin Watson wrote: > git-dpm does too, and I agree it's nice. here's an opposite data point: being forced to use git-dpm by the python-modules-team policy - i haven't had a single joyful experience with git-dpm. so far, every import of a new upstream release turned into a nightmare with an extra working clone of the repository, and skimming through the same man- and webpages full of outdated documentation even though i'm pretty sure that the required information was there the last time i looked. git-dpm might be useful if you use it daily. as it stands, i'm a very happy gbp user (without fancy addons) for almost all of my packages, and the few python modules i maintain don't do releases that often (which explains why i don't get a routine for doing new upstream imports with git-dpm). gfmrds IOhannes signature.asc Description: OpenPGP digital signature
Re: Default page view for salsa repositories
On 2018-01-22 16:14, Alexander Wirt wrote: >>> >> >> Depending on the version of salsa's gitlab, this MR might be applicable >> for debian/changelog: >> >> https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16550 >> >> The issue on the gitlab's tracker: >> >> https://gitlab.com/gitlab-org/gitlab-ce/issues/42272 > Then lets hope it gets accepted :) > hmm, while the MR is about something /similar/, afaict it will *not* (yet) allow us to set an arbitrary page to be rendered as the default page. :-( fgmasdr IOhannes
Re: Updated proposal for improving the FTP NEW process
On 2018-03-05 12:18, Gert Wollny wrote: > (1) Given that all new source package come with an ITP bug, when a > package must be rejected, the FTP team could CC this bug in the > rejection message. i would really like to see this. sometimes i miss rejection emails - or at least wonder whether i missed them. having a second place to look for such information would boost my confidence. fgasmdr IOhannes
Re: New package netgen-lvs with binary /usr/bin/netgen - already taken
On 9/7/18 10:10 PM, Ruben Undheim wrote: > 3. The netgen-lvs-base binary package comes with all the (main) files for >netgen-lvs. The executable will be called /usr/bin/netgen-lvs >It will NOT conflict with "netgen". > > 4. the netgen-lvs source package will be patched such that it works with the >executable called /usr/bin/netgen-lvs (there are some tcl scripts and > python >scripts) stupid idea: do these scripts (and other consumers of the netgen binaries) actually use the fully qualified "/usr/bin/netgen" or just an unqualified "netgen"? if the latter, you might just put the unchanged names into something like /usr/share/netgen/bin/ and tell users to add to that to their PATH when running their scripts. that provides a simple compat layer for out-of-distro scripts. rdeps in Debian should be patched to use debianized script-names. gfdasr IOhannes signature.asc Description: OpenPGP digital signature
Bug#864408: ITP: dehydrated-dnspython-hook -- dehydrated dns-01 challenge response support
Package: wnpp Severity: wishlist Owner: =?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= * Package name: dehydrated-dnspython-hook Version : 0.1 Upstream Author : Elizabeth Ferdman * URL : https://github.com/eferdman/dnspython-hook * License : GPL-3 Programming Lang: Python Description : dehydrated dns-01 challenge response support This package provides a hook script to serve dns-01 challenge responses for dehydated. . It uses the dnspython API to perform dynamic DNS updates, creating a temporary TXT record for the given domain, thereby proving ownership of the domain. It requires a DNS-server capable of performing dynamic DNS updates, like bind9. There is no need for the DNS-server to run on the local machine. . This is especially useful if you want to create ACME certificates for servers that do not serve HTTP and/or are not exposed to the public internet. Most ACME-related packages in Debian only deal with http-01 challenges. This one deals with dns-01. I intend to maintain this package under the "Debian Let's Encrypt" umbrella (provided that the team accepts this :-))
Bug#865419: ITP: libmysofa -- C library to read HRTFs stored in the AES69-2015 SOFA format
Package: wnpp Severity: wishlist Owner: =?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= * Package name: libmysofa Version : 0.4 Upstream Author : Christian Hoene * URL : https://github.com/hoene/libmysofa * License : BSD-3-clause Programming Lang: C Description : C library to read HRTFs stored in the AES69-2015 SOFA format Libmysofa is a light weight C-library intended to read SOFA (Spatially Oriented Format for Acoustics) files for spatial rendering. It hardly has any library dependencies and is suitable for embedded devices. . It reads SOFA files and checks whether the data complies to the "SimpleFreeFieldHRIR" conventions. In addition, it provides functions to look-up and interpolate the filters for a given orientation and to normalize the HRTFs (Head-Related Transfer Functions) to a reference level. apart from their general usefulness (for the spatial audio community), ffmpeg and vlc recently switched to libmysofa for reading SOFA-files, it might be a good idea to have these dependencies in Debian. I intend to maintain libmysofa under the pkg-multimedia umbrella.
Re: alioth down?
On 2017-09-20 14:50, Elimar Riesebieter wrote: > Hi all, > > what is the reason why alioth.debian.org can't be reached? A > traceroute for git.debian.org stops at bm-bl1.debian.org > (5.153.231.241). [#debian-devel] /topic 14:57 -!- Topic for #debian-devel: Alioth currently rebooting/fscking | [...] [#debian-devel]
Re: source.changes has wrong hash sum (Was: ftp master uploads disappearing?)
On 10/05/2017 06:53 PM, Andreas Tille wrote: > Bad checksums on loki_2.4.7.4-7_source.changes: Checksum mismatch for file > loki_2.4.7.4-7.dsc: b4d2841416822842e6e6b85c44e3f4f3 != > 7acc0c03ab3a269d117decd6dd692967 > > What to try next? following this conversation with interest, i also tried telling my gbp builds to produce both source and binary packages. i also get the "checksum mismatch" for the source.changes (not for the amd64.changes). my workaround for now is to just (re)run "debsign" on the source.changes. maybe someone has a better alternative (though my workaround is good enough to be able to test the binary packages and do a sources-only upload with a single build). gfmdsr IOhannes signature.asc Description: OpenPGP digital signature
Re: ISO download difficult
On 12/04/2017 04:41 PM, eamanu15 . wrote: >>3- if yes, let the user decide: >> >> "Your network card/wifi adapter needs non-free spftware to operate. You >> may choose to keep this install 100% free software, in which case you >> will have no network connection until you plug-in a supported adapter, >> or to install the non-free software required to drive your adapter. What >> do you prefer? >>[] stay free (no network) >>[] use network (install non-free software)" >> > +1 there's also the (already mentioned) use case where one network adapter (e.g. the wired one) will work fine, but you need non-free firmware for another adapter (wifi). while this will successfully bootstrap the system to a point where the user can launch a browser and duckduckgo why their wifi is not working (as long as they stay wired) and eventually fix it, i think it is still a kind of "bummer" experience for a *new* user, likely to turn them away. which might turn the questions into something like: [] stay free (no wifi) [] enable all network devices (install non-free software) (these are only meant to replace your suggestion in specific situtations) gfdsamr IOhannes signature.asc Description: OpenPGP digital signature
Re: Exclicitly or "implicitly" mark architectures a packages does not build
On 2017-12-20 15:51, Holger Levsen wrote: > On Wed, Dec 20, 2017 at 02:31:42PM +, Wookey wrote: >> As a porter I notice quite a few packages where the maintainer has >> made things 'tidy' by giving an explicit architecture list when really >> the unlisted ones were really just 'doesn't build there yet, or arch >> is new since I made the list', so making such a list was >> unhelpful. Often they really wanted to make a 'doesn't build on arch >> foo' list but we didn't have a mechanism for that (that's still not >> fixed SFAIK). So not giving a list at all is good if it can be >> avoided. > > It would be really good to have such a list, this would ease QA work on > "uncommon" archs. Background: for reproducible builds we're rebuilding > all sid/main packages on amd64, i386, arm64 and armel. And thankfully > people actually look at all these results, both for plain old ftbfs bugs > as well as for reproducible builds issues. > > Thus it would be great to mark such packages as "currently ftbfs on > $arch, we know that, it's not great, but expected". > but isn't this something that can be detected automatically? e.g. if <> on <> is not available in unstable and/or testing, exclude it from the rebuilds. gfaksdr IOhannes
wontfix close vs open (was Re: Exclicitly or "implicitly" mark architectures a packages does not build)
On 2017-12-20 15:31, Wookey wrote: > Leaving it open wontfix makes it easy for someone to find the issue in > the future and see what decision was made and why, and that the > current situation is as correct as we can currently make it. But > closing is also OK IMHO. The reasoning will still get archived. speaking of wontfix bugs: is there a way to hide wontfix bugs from the list of bugs on "my"¹ qa page? this might already be the case (afair i currently don't have any open "wontfix" bugs), but it is something that keeps bothering me, so i'm raising it now that i got the cue :-) the BTS is both for users (those who report a bug) and developers (those that fix a bug). i understand that the first group should be made aware that there are issues that aren't going to be fixed. otoh i think that the second group shouldn't be bothered with bugs that they have already discarded (unless they are in a mood of "let's revise former decisions"). aiui to cater for the first group, bugs are tagged "wontfix" and left open. for the 2nd group, it strikes me more logical to tag the bug "wontfix" and close it. to cater for the needs of both groups, i think it would be nice to have two different views on all bugs (of a package, of a DM/team, of ...): - all open bugs including those "wontfix" - all closed bugs including those "wontfix" is this something that's already there and i just missed it? fgamsdr IOhannes ¹ https://qa.debian.org/developer.php?login=someuser
Re: GitLab B.V. to host free-software GitLab for Debian project
On 07/11/2015 04:17 PM, Alessio Treglia wrote: > On Sat, Jul 11, 2015 at 2:29 PM, Pirate Praveen > wrote: >> I will be working on it. First task is to complete gitlab packaging. >> See balasankarc.in/gitlab for current status. > > That is quite a progress. Awesome, thanks! > indeed, that status page got my very excited. however, i wonder whether that page is actually getting the status live or if somebody forgot to update it in the last few months... keep up the good work! gfmasrd IOhannes signature.asc Description: OpenPGP digital signature
Re: GitLab B.V. to host free-software GitLab for Debian project
On 09/28/2015 08:41 PM, Balasankar C wrote: > Hi, > >> indeed, that status page got my very excited. > Maintainer of that status page here. :) >> >> however, i wonder whether that page is actually getting the status >> live or if somebody forgot to update it in the last few months... > > I just updated it with the latest master branch of GitLab and am > running a cron job checking the package status of each gems. May I > know why you feel that it isn't updated? Some new gems entered the > list recently and that's why the percentage declined. that was just a gut feeling. i haven't actually remembered how many packages were still missing last time i checked, but it didn't seem to make any noteable progress in the last 2 months or so. i might be totally mistaken (but i didn't find a quick way to assess the progress *speed*, so i asked here) thanks for the clarification. fgmrds IOhannes signature.asc Description: OpenPGP digital signature
Re: Bug#801842: ITP: python-pulp -- an LP modeler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2015-10-15 09:59, Thomas Goirand wrote: > Package: wnpp Severity: wishlist Owner: Thomas Goirand > > > * Package name: python-pulp Version : 1.6.0 Upstream > Author : Stuart Anthony Mitchell * URL > : https://github.com/coin-or/pulp * License : Expat > Programming Lang: Python Description : an LP modeler > > PuLP is an LP modeler written in python. PuLP can generate MPS or > LP files and call GLPK[1], COIN CLP/CBC[2], CPLEX[3], and GUROBI[4] > to solve linear problems. may i suggest to avoid excessive use of acronyms (of the 31 words in the description there are 12 acronyms), or at least add some hints for the lay audience what this package is about (e.g. "an archiver for vinyl cover art"). also, are those numbers in brackets meant to be footnotes? fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWH2xwAAoJELZQGcR/ejb40+EP/jsqEVnRXnP9IapYunkjGWDw YOy0ZV4YmYOEujG+gc8EtYHZ1zJK+VYDmpii1W4GTBKc1zzNaRFrlfIiuap7eKt3 h8S8y7qfn2P3Vlu4tG+uiW+3J8WcMl+5iBbt4fxDkM3E1sAp55NqWpoAQSEC9cKy ss7AGE1HypRPdK4tev4n1A4z27fFn4xreHQUSnKLzND29+oN8c3JOluYacYfJ/9y XeP9tGds7eWlhTm5Ymf+WvNUO8carAmI5Ht4fIno1eHI1kbkX7eKzAqOsuluDAZN t8CC67X67m4oFHyGKbCf6XDnXcEHVkWomLTLIZRvYSVQuQQYr9LjNvSweh+etJGV X7RJmYIgrEv6ecC8ksZ/3lnuTYKsIf4O05PERivSAc1a3xhzD77C41k1qev1fzbn jBpzo4FN16DvXi0ev96Q71u5c2lIuPju0Ax4VtslY+zHOi5ShSrKTti4Qvb0NrUB 8abV7EtETc3v8Sr8rbd/4B+XWQwsKlUw/v5pDofxUz5m49gQOOgimCUc/UVxGFdQ Pw0lvZPcGzz3gcYyjkmIJEpLE8pxTiEXVaAetSPz8ZHMIFLrsIpRgl+M70BXgt3+ aX5jPZvjjOMHBabY1oklff5B+Ysrc66z6OlLQaYnf+NbcVgPeaFB9MJ6nRs8wuqn GWZfKOUC8DQWwOiD6Gn2 =9tF+ -END PGP SIGNATURE-
Re: Decreasing packaging overhead
On 2015-11-02 22:55, Thomas Goirand wrote: > It's not the package which is a bad practice, here, the maintainer is > only dealing with upstream. > > What's a bad practice is creating a library for 2 lines of code. > Upstream should have tried to integrate this function into a bigger > library with more functionality to make it more useful. i resent the notion that either is bad practice. the problem merely reflects that Debian's concept of packages does not map well to other communities' concepts of packages (and i think i'm in line here with josh). our tried and tested concept of packages/libraries has been working for decades. young and emerging software development processes (might) have different needs. fgmasdr IOhannes
Re: GitLab B.V. to host free-software GitLab for Debian project
On 2015-09-28 20:09, IOhannes m zmölnig (Debian/GNU) wrote: > On 07/11/2015 04:17 PM, Alessio Treglia wrote: >> On Sat, Jul 11, 2015 at 2:29 PM, Pirate Praveen >> wrote: >>> I will be working on it. First task is to complete gitlab packaging. >>> See balasankarc.in/gitlab for current status. >> >> That is quite a progress. Awesome, thanks! >> > > indeed, that status page got my very excited. > [...] > > keep up the good work! > i'm glad to see that "gitlab" has entered experimental! fgamsdr IOhannes
Re: Are two Vcs-{Git|Svn|...} and Vcs-Browser fields sensible?
On 01/31/2016 10:47 AM, Jonas Smedegaard wrote: > > Instead of introducing new flags, I suggest to extend existing flags to > support "relative URLs" which are somewhere within Debian. > > E.g. [...] > > Vcs-Git: pkg-perl/packages/ciderwebmail > yes please. i very much liked andreas' basic idea, while at the same time very much disliked the adding of yet another set of tags. jonas' suggestion fixes these issues. gfmards IOhannes signature.asc Description: OpenPGP digital signature
Re: another mount issue on jessie
On 2016-02-09 20:03, Bas Wijnen wrote: > On Tue, Feb 09, 2016 at 10:38:26AM -0700, Sebastian Kuzminsky wrote: >> On another Jessie machine I had to apply the same workaround to some >> additional services. I identified the services that needed the workaround >> by grepping for 'PrivateTmp' in /lib/systemd. > > So any program that uses this option is broken? Doesn't that mean we should > always disable it? Is there a reason that it is ever enabled for anything? > hmm @sebastian: could you confirm that you had to remove the PrivateTmp for each and every service you found by grepping? or did you just disable PrivateTmp for all of these services, and then no more problem occured (though by chance you might have disabled PrivateTmp for some services that would have actually worked with it). fgmadsr IOhannes
Re: 50.000 binary packages
On 2016-02-10 14:19, Thomas Goirand wrote: > There's an RC bug... :P > > # ./pkgquiz > Collecting package information... that's because you are in cheat mode. try playing with "--hard". ghsdt IOhannes
Re: GitLab B.V. to host free-software GitLab for Debian project
On 2016-02-10 23:12, Pirate Praveen wrote: > On Friday 22 January 2016 10:20 PM, Balasankar C wrote: >> On വ്യാഴം 21 ജനുവരി 2016 07:11 വൈകു, Pirate Praveen wrote: >>> I need help with integrating debconf for configuring hostname. Somehow I'm >>> not able to troubleshoot the error. It seems I'm missing something simple, >>> I tried to follow debconf tutorial and compare many times, but only to see >>> a cryptic error message. >>> >>> https://gitlab.com/debian-ruby/TaskTracker/issues/41 >> >> This issue has been fixed. Two echo statements (for verbosity) used >> before loading confmodule caused the issue. Removed them and debconf is >> no longer an issue. >> >> > > Now gitlab in unstable is rc bug free and can migrate to testing (if we thank you very much for all your efforts! now i only need a migration plan :-) fgmasdr IOhannes
Re: How to deal with "assets" packages shadowing real upstream
On 2016-03-08 19:23, Bas Wijnen wrote: > On Mon, Mar 07, 2016 at 03:12:10PM +0100, Jonas Smedegaard wrote: >> > Oh - I just discovered that this _is_ covered by Policy §4.13 already. > Reading that again, I see that it says code copies are acceptable if the code > is meant to be used that way (with GNU autotools as an example in the > footnote). For convenience, I quoted the whole thing below. thanks for the quote (saved some time). i think that §4.13 does not cover the original issue of jonas at all, as it's about something different: using convenience copies instead of the system provided packages. the case being discussed is (i believe): - upstream releases of "foo" contain a component "bar" - "bar" is not an *integral* part of "foo" (it's a dependency) - nobody has packaged "bar" yet - may the packaging of "foo" then rely on the included "bar", or do we have first have to package a standalone release of "bar"? i don't think that there is anything inherently wrong using the included "bar". esp. if the packager actually does split the "bar" component into a separate binary package so it's usable by other packages as well. actually, i think in some cases it's even the better approach...think of all that tiny js packages; wouldn't everybody be happy if they were accumulated into a bigger upstream, even if this upstream was just a proxy to the "real" upstreams? however, if "bar" gets packaged on it's own (which probably only makes sense if it provides additional features - e.g. because the repackaged source stripped out some components and/or doesn't track upupstream's development closely), then i guess this one should become the one to be used by other Debian packages (conforming to §4.13). obviously (and hopefully) after an agreement between the maintainer of "foo" and the prospective maintainer of "bar". fgmasdr IOhannes
gitlab package (was Re: Opt out style recommends)
hi,
On 04/08/2016 05:33 AM, Pirate Praveen wrote:
> See #819854 for a background.
>
> Currently gitlab recommends letsencrypt, it means someone has to opt in for
> letsencrypt by running something like
>
> apt-get install gitlab letsencrypt
>
> But I would like letsencrypt to be available by default (postinst asks if
> they want t
while i really appreciate all the work you are doing for the gitlab
package, i honestly have the feeling that you are trying to make too
many decisions on behalf of the system administrator who wants to
install gitlab.
i really don't see any compelling reason why a package like gitlab
should force me to use any special means to encrypt my connection.
there are a number of reasons to use the Debian gitlab packages over the
ones provided by upstream (e.g. omnibus), and one of them is being able
to chose the components i would like to have on my system (or not).
but the way the package is heading seems to take away choices rather
than give me additional ones: e.g. using upstream's gitlab-ce omnibus
packages i am *free* to choose whatever method i like to setup an
encrypted webserver (allowing me to e.g. setup a gitlab instance that is
not accessible from the public internet - something that is impossible
with letsencrypt afaict).
i would love if the gitlab package in Debian was as *minimal* as
possible giving *me* (the admin) the freedom to choose the largest
possible set of components - probably (and likely) at the expense that I
(the admin) will need to setup quite a lot of things myself.
i guess there are *many* things to setup and this might make it
impossible for newbee administrators to setup their own gitlab instance.
but i think that there are ways to accomodate both the seasoned admin
(probably in a corporate environment dictating whatever policies) and
the any random developer (who want an instance for their personal use
without worrying too much about administration).
e.g. instead of making the 'gitlab' package work magic and conjure the
perfect configuration for any usecase, you could instead:
- add *good* documentation; with configuration examples, step-by-step
instructions to setup whatever additional service,...
- provide an *additional* package ("gitlab-to-go", but please cose a
better name :-)) which depends on 'gitlab' (and other packages like
'letsencrypt') and which does the magic to provide the "it just works"
experience for selected use-cases.
i really hope that this will simplify your work as a maintainer of such
a complex package. (or put otherwise: i think that the quest to come up
with a satisfying configuration for all potential users is NP-complete
and will indefinitely stall further packaging or make the package
unusable for some users or both)
a nice side effect might be that it would allow Debian gitlab packages
follow upstream more closely (e.g. Debian currently has
gitlab-8.4.3+dfst-12 whereas upstream currently has 8.6.4 (and the 8.4
series is at bugfix release 8.4.7; the numbers might be a bit misleading
though, as Debian might not be affected by a few bugs that triggered
there own bugfix release).
anyhow, thanks again for doing all the work to bring us gitlab.
fgmards
IOhannes
signature.asc
Description: OpenPGP digital signature
Re: gitlab package (was Re: Opt out style recommends)
On 2016-04-10 03:55, Pirate Praveen wrote: >> >> while i really appreciate all the work you are doing for the gitlab >> package, i honestly have the feeling that you are trying to make too >> many decisions on behalf of the system administrator who wants to >> install gitlab. > > I just want the service up and running after you install gitlab. Isn't it how > every other service doing it? yes sure. but if i install other web-services (e.g. php-horde) they don't bother me with setting up an enrypted webservice. the only reasonable package that should suggest ways of encrypting seems to be the webserver (apache2, nginx,...) > >> i really don't see any compelling reason why a package like gitlab >> should force me to use any special means to encrypt my connection. > > It does not. Even earlier with letsencrypt in depends, it asks in post > install if letsencrypt should be used. Now it is in recommends and you can > just skip letsencrypt. cool. thank you. >> there are a number of reasons to use the Debian gitlab packages over >> the >> ones provided by upstream (e.g. omnibus), and one of them is being able >> to chose the components i would like to have on my system (or not). > > It is just the first attempt and making all components optional is in my > todo. Patches to speed it up is welcome. > > nginx is already made optional in last update. Next is database. i see. since you were basically starting from this huge monolithic installation, it makes sense to first get the package running and then factor out as much as possible. > > Its already 8.5.8. Three new gems are required for 8.6 and we are already > working on it. > fantastic. famtsd IOhannes
Re: gitlab package (was Re: Opt out style recommends)
On 2016-04-11 11:48, Pirate Praveen wrote: > It would be a good time to add letsencrypt support to php-horde and every > other service dealing with sensitive data like passwords. no, seriously not. i am all for having all web traffic encrypted. that's why the web-server package *may* push for encryption (by suggesting letsencrypt or whatever). however, it is none of the web-application's business. and gitlab is just that: a web-application. fgmsdr IOhannes
Bug#1087939: ITP: pd-slip -- SLIP encoder/decoder for Pure Data (Pd)
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org Owner: IOhannes m zmölnig (Debian/GNU) Severity: wishlist * Package name: pd-slip Version : 0.1 Upstream Contact: https://github.com/pd-externals/slip * URL : https://github.com/pd-externals/slip * License : GPL-2+ Programming Lang: C Description : SLIP encoder/decoder for Pure Data (Pd) This library implements the Serial Line Internet Protocol (SLIP), a simple protocol for encapsulating packets within a streaming transport protocol such as TCP/IP or on the serial port. . You will need this if you plan to transmit e.g. OSC messages via TCP/IP or the serial line. There's already a pd-slip binary package in Debian (from src:pd-mrpeach). Upstream has factored out the pd-slip part into a separate project, and I would therefore like to track this in a separate source package. I intend to maintain this under the multimedia-team umbrella.
Re: ITN procedure?
Hi, 在 2025/5/9 02:24, Lucas Nussbaum 写道: > On 08/05/25 at 16:56 +0200, Bálint Réczey wrote: >> I agree with using existing processes and I also appreciate Andreas' >> initiative to improve the state of long-neglected packages. >> >> I believe the ITN name is a bit redundant, since our NMU process with >> an upload to a delayed queue already signals an intention ahead of the >> change (i.e. getting the updated package accepted to the archive) >> happening. >> Slightly expanding the NMU process scope would be sufficient to handle >> such more intrusive changes, since we just need to cover a bigger >> *update* from a *non-maintainer*. > > I agree I agree. We can use NMU ITS Orphaned RFA ITA RFH etc,. processes to deal with. Debian already had so many processes. Slightly expanding these processes is better. - Bugs filed against the package do not have answers from the maintainer. Any people can help answer bug report, supply patch, etc,. NUM is allowed for new upstream version bug and release-critical, important bugs. - There are QA issues with the package. Allow do QA upload for some type of QA issue. - Not on Salsa but it could profit from team maintenance Salsa, even git repo is not *must* for the package maintain. The package maintainer has right to decide use or not use git. Use git rebase to maintain the commit log is also take much time. If package maintainer would transfer to team maintenance is no problem. - Not uploaded by you in the last 5 years Do mass bug filing for it? or allow do a source-only NUM upload? or also allow update the copyright year info? - Standards-Version < 4 Is there the plan or roadmap to improve old Standards-Version package? For example, set the deadline for Standards-Version < 4, do mass bug filing. If package maintainer don't update until the deadline, raised the bug severity, then use NMU to upload. I'm sorry for my poor English. I hope you can understand. Best regard, -- 肖盛文 xiao sheng wen -- Debian Developer(atzlinux) Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40debian.org Debian salsa: https://salsa.debian.org/atzlinux-guest GnuPG Public Key: 0x00186602339240CB OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Q: Ubuntu PPA induced version ordering mess.
On 7/3/24 00:28, Alec Leamas wrote: The upstream shall consider adopting 5 digit release version numbering [...] The upstream "shall" not do anything, they are open for discussions but certainly not for dictates. thou shalt not ask if thou wisheth for no answers. (please keep in mind that not all Debian contributors are native speakers so you probably should go easy on the subtle differences between the various subjunctive forms. so unless somebody uses "SHALL (as in RFC-2119)", I would assume that the "shall" is a mere suggestion). If you are able to sell this idea to upstream it would certainly work. I would not try it, it would generate a lot of friction to no use. And at afaict, all suggestions end with that same argument: upstream would resist. which makes the discussion a bit moot. anyhow here's my 2¢: according to you¹, upstream have simply botched their package versioning, which i would consider *a bug*. bugs cause pain. if upstream acknowledges that it *is* a bug, they might be interested in fixing it (even if the fix causes more intermediate pain). if they don't, I personally would go for a workaround like an epoch :-) and some other idea (not very well through through, it's still early in the morning and the caffeine level is low): depending on the ecosystem, you might get away with using an epoch only for the frontend application package. e.g. if there is a meta (binary) package "opencpn" that depends/recommends/... on various opencpn libraries, plugins and what not you could bump the epoch for this package only and have some clever Breaks against the too-high versions, which should eventually force the users to downgrade/re-install the child packages. gdfasmr IOhannes ¹ i looked up <https://launchpad.net/~opencpn/+archive/ubuntu/opencpn/+packages> and did not see any problematic package versions (i probably did not look long enough). so which (actual) package/version is this about? OpenPGP_0xB65019C47F7A36F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Please help me fix the build pipeline for apt-listchanges on Salsa, which is failing
On 9/2/24 03:19, Jonathan Kamens wrote: However, the pipeline is still failing, now in reprotest. For example <https://salsa.debian.org/debian/apt-listchanges/-/jobs/6215633#L1650>. Perhaps this is because I haven't yet finalized the changelog for the upcoming release so the trailer line is badly formatted. :shrug: nope. it's failing, because the .deb files are not identical. if you do not want to run reprotest locally and still have a closer look at the differences, you can download the build-artifacts (that is: the .deb files produced by the job at [1]) and inspect them with diffoscope, to see that the files in the tarballs have different timestamps (which obviously makes them non-reproducible. note: this is just general advice, i haven't looked at the *actual* package. gfmasdr IOhannes [1] <https://salsa.debian.org/debian/apt-listchanges/-/jobs/6215633/artifacts/download> OpenPGP_0xB65019C47F7A36F8.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On Thu, 19 Jan 2006 11:41:19 +0100, Frank Küster <[EMAIL PROTECTED]> said: > Hi, the text of the amendment says at its very end: > , >> Since this amendment would require modification of a foundation >> document, namely, the Social Contract, it requires a 3:1 majority >> to pass. > ` > But AFAICS it does not propose a textual change to the SC, just a > change of its meaning, or interpretation or whatever. I am afraid I was responsible for that rider. I should apologize for not sending a clarification earlier, but I was inadvertently away from my keyboard since my laptop's graphics card died just as I was going off on a business trip > I have a couple of questions about this: > - Has this been done previously? If yes, where can I find a > collection of all decisions that have thus "changed" the SC? Err, we have had two GR's that changed the SC -- the so called "editorial changes" GR, and the GR that deferred the changes for Sarge. But in each case we followed through and changed the text of the SC. > - Shouldn't we add a sentence to the SC, something like "In a couple > of cases, the interpretation of this Social Contract or how it > should be spelled out in technical details was controversial among > the project, and votes have been taken. The results of these > votes are at hyperlink> "? > As for the intention of the amendment, it seems to me that it relies > heavily on the assumption that the excempted clauses are simply bugs > of the license text and not the actual intention. Given how bad > communication with the FSF was wrt to the GFDL, I doubt that we can > sure about this... The fact that the license is buggy does not change the fact that works licensed under it would violate the DFSG. Given that, any resolution to allow these works to remain in Debian would require a rider to be added to the SC, something of the form: - Debian will remain 100% free + Debian will remain 100% free, apart from works licensed under the GFDL (the exact wording can be decided upon if the amendment passes). Since this requires a modification of a foundation document, the amendment requires a 3:1 majority. manoj -- signal(i, SIG_DFL); /* crunch, crunch, crunch */ Larry Wall in doarg.c From the perl source code Debian Project Secretarty <[EMAIL PROTECTED]> <http://vote.debian.org/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpzsSjINPdGk.pgp Description: PGP signature
Re: delay of the full etch freeze
Le Wed, Oct 11, 2006 at 06:58:55PM +0200, Andreas Barth a écrit : > > For these reasons, we are delaying the full archive freeze for a few days. > We haven't chosen a date yet, but you can still expect it to happen in > October or early November. Dear Andreas, May I suggest to delay the freeze as long as it is necessary for the packages which were uploaded to NEW before the 8th to enter in Etch if they have no bugs? The rationale is that the 8th is "old freeze deadline minus 10 days", so it was not completely unreasonnable to take this day as the deadline for having new packages in Etch. Unfortunately, the time a package stays in NEW is completely unpredictable, it has been 0-3 days most of the time, except around Debconf and this month, where is is more something like 1-3 weeks. As a consequence, packages uploaded one week before the old freeze deadline minus 10 days can not enter in Etch. With the delay, you have an opportunity to correct this "downstream". By setting the cutoff on packages uploaded before the 8th, you would ensure that the uploads were not targeted for sid only, as a migration to etch was expectable. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
Hi,
As I count, this resolution to delay the decition of the DPL
of the withdrawal of the Package Policy Committee delegation has
received 2K sponsors, which means that § 4.2.2.2 of the constitution
to be called into action.
,
| 4. The Developers by way of General Resolution or election
| 4.1. Powers
| 3. Override any decision by the Project Leader or a Delegate.
| 4.2. Procedure
| 2. Delaying a decision by the Project Leader or their Delegate:
| 1. If the Project Leader or their Delegate, or the Technical
| Committee, has made a decision, then Developers can override
| them by passing a resolution to do so; see s4.1(3).
| 2. If such a resolution is sponsored by at least 2K Developers,
| or if it is proposed by the Technical Committee, the
| resolution puts the decision immediately on hold (provided
| that resolution itself says so).
| 4. If the decision is put on hold, an immediate vote is held to
| determine whether the decision will stand until the full vote
| on the decision is made or whether the implementation of the
| original decision will be delayed until then. There is no
| quorum for this immediate procedural vote.
`
So, an immediate procedural vote has to be held to determine
whether the decision will stand until the full vote, on the decision
is made or whether the implementation of the original decision
(i.e. withdrawl of delegation from the policy delegates) will be
delayed until then.
I am proposing the following draft ballot for this immediate
vote, while I go about setting up the voting infrastructure. The
vote page containing the details of this general resolution is not
yet up, but as soon as it is it would be found at:
http://www.debian.org/vote/2006/vote_008
manoj
`This is a DRAFT ballot. Voting is not yet open.
==
Voting period starts 00:00:01 UTC on Friday, 28 Oct 2006
Votes must be received by 23:59:59 UTC on Friday, 10 Nov 2006
The following DRAFT ballot is for voting on a immediate procedural vote to
determine if the Debian project Leaders decision to un-delegate policy
delegates remain on hold until the full vote is called, in accordance
with section 4.2.2.4 of the Debian constitution. The vote is being
conducted in accordance with the policy delineated in Section A,
Standard Resolution Procedure, of the Debian Constitution.
You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions contact [EMAIL PROTECTED]
HOW TO VOTE
Please read the debian-vote@lists.debian.org mailing lists for details
on why this procedural vote is being called.
Do not erase anything between the lines below and do not change the
choice names.
In the brackets next to your preferred choice, place a 1. Place a 2 in
the brackets next to your next choice. Do not enter a number smaller
than 1 or larger than 2. You may skip numbers. You may rank options
equally (as long as all choices X you make fall in the range 1<= X <=
2).
To vote "no, no matter what" rank "Further discussion" as more
desirable than the unacceptable choices, or You may rank the "Further
discussion" choice, and leave choices you consider unacceptable
blank. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices. (Note: if the Further
Discussion choice is unranked, then it is equal to all other unranked
choices, if any -- no special consideration is given to the Further
discussion choice by the voting software).
Then mail the ballot to: [EMAIL PROTECTED] Don't worry
about spacing of the columns or any quote characters (">") that your
reply inserts. NOTE: The vote must be GPG signed (or PGP signed) (or
encrypted) with your key that is in the Debian keyring.
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
2808c3bb-6d17-49b6-98c8-c6a0a24bc686
[ ] Choice 1: The DPLs decision remains on hold until the full vote
[ ] Choice 2: Further discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
------
The responses to a valid vote shall be signed Devotee (DEbian VOTe
EnginE) using by the vote key created for this vote. The public key
for the vote, signed by the Project secretary, is appended below.
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.5 (GNU/Linux)
mQGiBEVBK6wRBACsbjlsanpIl1F4IT6sWiML/khpUQjqtywggKt9hG0k4XpCIvsZ
YzioNdJyzODLCTCZWmmUEA1P5mSPKPosvqopp967wpF0fyu2TLoTNJnCsDCnSz3q
aofhlAF1LaOwfLDRpNFCW2J7bE+ELWBUhbPCN86T0D0ElelIvJvlR+maSwCgicvT
ClbqL2WuiYkLSLhnIk6BmI0D/Rd2ZO1/wXuWmYHacD1rOxKVxk8Zn5/1zDE+VaL1
K2ZYMdDCZMojxjncEtEQU3oKDuKwggSn/lYfXsNNEaeqafNnIDMpNlYT
Bug#357791: ITP: irc2html.scm -- Convert IRC chat logs into valid HTML with valid CSS
Package: wnpp Severity: wishlist Owner: "MJ Ray (Debian)" <[EMAIL PROTECTED]> * Package name: irc2html.scm Version : 1.2 Upstream Author : MJ Ray <[EMAIL PROTECTED]> * URL : http://mjr.towers.org.uk/software.html#other * License : GPL Description : Convert IRC chat logs into valid HTML with valid CSS Yet another converter from IRC log files to HTML, but this one produces valid xhtml which really annoyed me about the other ones I found. It's not hard to do and it's essential for accessibility. I also think the colour selection algorithm is pretty neat too, hashing nicks with overrides possible. It optionally takes one argument, which is put in the HTML page title. It reads a common ircII log file from stdin and generates HTML on stdout, so use pipes or < and > to redirect them to useful places. Debug information should come to stderr. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (989, 'testing'), (500, 'stable'), (99, 'unstable') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.18-bf2.4 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re:
General info Subscription/unsubscription/info requests should always be sent to the -request address of a mailing list. If a mailing list is called for example "[EMAIL PROTECTED]", then the -request address can be inferred from this to be: "[EMAIL PROTECTED]". To subscribe to a mailing list, simply send a message with the word "subscribe" in the Subject: field to the -request address of that list. To unsubscribe from a mailing list, simply send a message with the word (you guessed it :-) "unsubscribe" in the Subject: field to the -request address of that list. In the event of an address change, it would probably be the wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe to the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be "Re:", without the quotes of course); the -request server does not react to replies. The archive server -- Every submission sent to this list is archived. The size of the archive depends on the limits set by the list maintainer (it is very well possible that only, say, the last two mails sent to the list are still archived, the rest might have expired). You can look at the header of every mail coming from this list to see under what name it has been archived. The X-Mailing-List: field contains the mailaddress of the list and the file in which this submission was archived. If you want to access this archive, you have to send mails to the -request address with the word "archive" as the first word of your Subject:. To get you started try sending a mail to the -request address with the following: Subject: archive help The listmaster -- To reach a human being answering your mail you may contact the address [EMAIL PROTECTED] We will process your request as soon as we can. Mail sent to this address is pre-parsed, a little mail robot will automatically answer all mails sent with the following Subject lines: help sends this help lists sends information on how to get a list of mailing lists -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re:
General info Subscription/unsubscription/info requests should always be sent to the -request address of a mailing list. If a mailing list is called for example "[EMAIL PROTECTED]", then the -request address can be inferred from this to be: "[EMAIL PROTECTED]". To subscribe to a mailing list, simply send a message with the word "subscribe" in the Subject: field to the -request address of that list. To unsubscribe from a mailing list, simply send a message with the word (you guessed it :-) "unsubscribe" in the Subject: field to the -request address of that list. In the event of an address change, it would probably be the wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe to the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be "Re:", without the quotes of course); the -request server does not react to replies. The archive server -- Every submission sent to this list is archived. The size of the archive depends on the limits set by the list maintainer (it is very well possible that only, say, the last two mails sent to the list are still archived, the rest might have expired). You can look at the header of every mail coming from this list to see under what name it has been archived. The X-Mailing-List: field contains the mailaddress of the list and the file in which this submission was archived. If you want to access this archive, you have to send mails to the -request address with the word "archive" as the first word of your Subject:. To get you started try sending a mail to the -request address with the following: Subject: archive help The listmaster -- To reach a human being answering your mail you may contact the address [EMAIL PROTECTED] We will process your request as soon as we can. Mail sent to this address is pre-parsed, a little mail robot will automatically answer all mails sent with the following Subject lines: help sends this help lists sends information on how to get a list of mailing lists -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
Aach, no sleep for the wicked this darkling eve ... at least not for me. or morning, whatever. On Wed, Sep 13, 2000 at 07:57:41AM -0400, Christopher C. Chimelis wrote: > > Good point :-) I hope NM can be improved as well. I've got someone that > I know will help the Alpha port that's still in process after several > months now, but it's like molasses flowing uphill in winter to get him > finally in the project. I hope so too! > > a. Assign more people to process applications - kind of > > self-explanatory. > > Not to stir anything up, here, but, to the NM team, what exactly is "the > process" for dealing with NM applications? I've tried to stay away from > politics mostly, but I've always been curious about this. I know it > involves a phone call, getting ID proof, and getting their key signed, but > other than that, I'm clueless. To help streamline it, is it something > that (technically) any of us can do if we know the person or are closer > geographically to them than the normal members of NM? Good Question. Takers? > > b. Establish at least two teirs of contribution - people who are > > interested in helping with less technical aspects need not be subjected to > > the same screening process as package maintainers. So if, for example > > somebody says "hey, could I help with paperwork or the website or > > something ?" they can be easily accepted to work on something. Voluteering > > should not be a full time job. > > We get offers, but I kinda agree with the rest on this > issue. Documentation, IMO, is just as important as the software > itself. I know we don't always practice that principle, but we > should. To maintain docs on par with the quality of the software > releases, I'd personally feel more comfortable knowing that anyone that's > taking care of docs has the same knowledge/credentials/whatever that the > package maintainers do. That's a good point - at least as far as actual composition goes. But there are parts of the whole process of documenting that really don't require that much background; eg. general editing, grammar, style, putting things into formats, ie. general presentation. Sometimes somebody less knowledgable will have the best feedback - they are, after all, the primary beneficiaries. And what may be a clear description to a developer is not necessarily clear to a user. I happen to know an excellent technical writer that would be happy to pitch in but he knows very little about linux so ... > > c. (optimally) Rewrite the pages that explain how to apply and > > give a clearer and more complete description of tasks available and what > > level of expertise each requires. > > I'd like to see this as well, but lack the time to volunteer to improve > it. I've got enough tasks just keeping Alpha going, porting HURD to > Alpha, seeking a job (yes, I'm unemployed), keeping my wife from throwing > my computers off of the balcony, and keeping up with my Quake clan duties > :-P I also think that whatever it is that NM does while processing an > application should be documented (not per person, just in general...I > think applicants would like to know what the steps are that you're going > through while they wait). > > > d. (optimally) simplify the protocols for applying. > > Hmmm...expand on this, please...I'm not clear on what "protocols for > applying" means. Actually I was refering to what you just described - all of the steps involved in applying. It is very difficult to even gather what those steps are; seems like this could be consolidated and streamlined somewhat for at least some kinds of participation. Preferably any, although I understand the concern for quality. Still there is a point of diminishing returns with QA. > > Hahahaha...I ftp'ed the debs, but was wondering if there's a source > package around. I usually like to prod at stuff without installing it (I Its in CVS: pserver:[EMAIL PROTECTED]:/cvsroot/unilinux co ddoc - I think that is working now, haven't actually checked recently. cheers, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Wed, Sep 13, 2000 at 01:52:36PM +0200, Josip Rodin wrote:
> On Mon, Sep 11, 2000 at 04:39:33PM -0700, erik wrote:
> > I realize I stirred up a hornets nest; I did it intentionally because
> > otherwise nobody seems to notice and I think that at least some of what I
> > originally wrote (goading aside) is important.
>
> Personally, I would like a normal post better. I read 4-5 lines of your
> initial post, after which I instantly decided it's a flamebait and moved on
> to the next message.
Yes, I am sure most people would. However, I have noticed that normal posts
on topics of this nature are handily dispatched with singular consistancy,
usually with reference to historical discussion buried somewhere deep in the
list archives. Or just ignored.
Squeaky wheels, Drastic Measures, Desparate Times and all that.
Some times the grotesque is simply the most engaging. Caught _you_ checking
back in, didn't we? :;-}
> This is Debian, so s/Assign more people/Get more volunteers/.
Beware circular logic. This just means that the first thing to do is accept
people that would like to learn the ins and outs of the application process. It
would be well worth the time to teach them, don't you think?
>
> We have quite a few translators who aren't developers but do have CVS access
> to the web site repository, actually. All it takes is to mail the
> appropriate person (debian-www or the translation coordinator).
>
If that is the case then two things could happen:
a. apply the same standards of access for some other
things that need attention and
b. Post information on this prominantly
> Don't know about debian-doc, it's probably more or less the same (mail the
> list or the doc coordinator).
Personally, I have never recieved any acknowledgement that anyone even
looked at mail I have sent ... and, no, I'm not really habitually obnoxious:).
They probably got tossed with a thousand other emails, really quite normal
in a large organization.
Regards,
Erik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Wed, Sep 13, 2000 at 10:05:26AM -0400, Raul Miller wrote: ...sigh. Exhibit A: > On Mon, 11 Sep 2000, erik wrote: > [lots of stuff deleted -- basically a bitch about new maintainer] > > On Wed, Sep 13, 2000 at 07:57:41AM -0400, Christopher C. Chimelis wrote: > > Good point :-) > > Not really: > > [1] This point (if it really erik's point -- hard to tell) is > not well expressed by erik's subject line, and was not well expressed > in any of erik's original posts. Even the current post is way to > verbose to be worth quoting. > > [2] New Maintainer is a tough job, with a lot of work to be done > (especially because we weren't processing applications at all, last > year, because things had gotten so out of hand and the people dealing > with it had gotten so stressed out). In spite of that, NM is processing > people at a fairly decent rate (and most of the people who haven't been > processed haven't had their identities confirmed, yet). > > > Not to stir anything up, here, but, to the NM team, what exactly is "the > > process" for dealing with NM applications? > > Please read: http://nm.debian.org > > -- > Raul > Oh well, at least nobody can say, "Well, nobody ever said anything ... ". I tried. Regards, Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: nice demolition job ... epilog
On Wed, Sep 13, 2000 at 10:54:32PM -0300, Nicolás Lichtmaier wrote: > > Purpose of Rant: Stir up the coals ... > > Have you already put some meat? > Yes, but unfortunately it was all devoured immediately by ravenous wolves. Barely raw as well... and apparently there was some indigestion thereafter. Pity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
retitle 180188 ITA: Defoma
retitle 180188 ITA: Defoma -- Debian Font Manager N.B. Here follows the description as is in the stable distribution: Defoma, which stands for DEbian FOnt MAnager, provides a framework of automatic font configuration. An application whose configuration of fonts requires users' hand can make the configuration process automated through Defoma, by installing a Defoma-configuration script to Defoma. The script gets called whenever a font is installed and removed, so that the script updates the configuration. Font packages should register their fonts to Defoma in order to have them configured automatically for applications. -- Fielder George Dowding, Non-maintainer
retitle 180188 ITA: defoma
retitle 180188 ITA: defoma -- Debian Font Manager thanks
Bug#541690: ITP: ttf-indic-nonfree-fonts -- Nonfree fonts for Indic languages
Package: wnpp Severity: wishlist Owner: "Debian-IN team" * Package name: ttf-indic-nonfree-fonts Version : 0.1 Upstream Author : various * URL : N/A * License : various nonfree Programming Lang: N/A Description : Nonfree fonts for Indic languages This package will collect some Indic fonts which can be redistributed by Debian but fail the DFSG for other reasons. -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (899, 'stable'), (100, '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
Re: CDD: GastroLinux (RFC)
Le Fri, May 11, 2007 at 02:41:41PM +0200, RalfGesellensetter a écrit : > Dear list, > > Custom Debian Distributions are getting en vogue: After Debian-Edu > (Skolelinux) and Debian-Med, Debian-Office had been proposed. > > Now, I bear this idea in mind: > > Combine too major tasks that pubs and restaurants need in one Distro: Hi Ralf, Beware that in (at least fr_FR) french, "gastro" is also a shortcut for "gastroenteritis" and is strongly associated with its symptoms! It may really hamper your success in french-speaking countries... Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Posting to debian-bugs-dist is not allowed
> >Hi, >Is there an easy way to make a chart automatically include new rows as >they are entered? >I currently have a spreadsheet with three columns: A, B and C. >Column A contains dates (i.e. the period, ex: June 2005) >Column B and C contains figures for the period. >your post will take 3-10 hours to appear. Not more than 5 minutes >later I received a E-mail reply to the post. I could not view my post >until 5.5 hours later at 12:30 in the morning. I replied back to the >E-mail and asked him how he seen the post so quickly. He said he just >seen it come up and that the post time delay may have something to do >with my ISP! I sent a question to Google groups support but their >reply was they were very busy and it may take some time to respond! I >checked their FAQ's to no avail. My ISP is a cable company DSL hi >speed line. >Can anyone shed some light on this. Is there anything the member can >do differently to see these posts as soon as they are released. If it >is the ISP what do you tell them to do differently? Is there a better >URL or IP address to access?? >Appreciate any replies, >Rich >When I copy and paste printed text to news group post, the line breaks from >the original publication are retained and result in >something like: >-- >POSTED 8:54 a.m. EST; UPDATED 9:21 a.m. EST, March 5, 2007 >PACKERS CHASING BELL >Bell was acquired by the Lions last week as part of the Dre' Bly deal. As >we've reported, both Bell and former Broncos tackle >George Foster are candidates to be traded again. >We're also told that the Packers contacted the Bears about the availability of >running back Thomas Jones, but the Bears said that he >is not available. It remains to be seen whether the Bears would be willing to >trade him to a team other than their intra-division >arch-rivals. >src="http://www.img9.org/uploads/a341b77b81a2e9e9f484e5bb312783c0.jpg";> > >-- >I think it might have something to do with >Tools/Options/Send/News Sending Format >Can the off the automatic word wrap be disabled? >I've heard that there's another Two-Wheeled Tuesday somewhere >west of the city. Anyone been there or know of any others in the >area? >I've seen a different version of the Macross Plus LDs called >Macross Plus International Edition. I asked somebody about >them and my friend said they're supposed to be something >similar to the Pioneer LDs, english on the digital track, japanese >on the analog, and closed captioning. Can somebody please >confirm this? (so I can go out and buy these LDs right now :) >Wilson Verardi >I'm selling on eBay (link below) a brand new condition copy of the "jp >airline-fleets international edition 96/97". This is the most >comprehensive guide to the airline fleets of all countries. Includes >info on complete fleets, types of aircraft, numbers, registration >numbers, etc. A very impressive book. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Discussion period: GR: DFSG violations in Lenny
Hi, At this point, the following people have sponsored and seconded the proposals detailed below. As best I can tell, the final proposal (4) to get enough sponsors got it at Sun, 9 Nov 2008 14:38:41 UTC. So, we now have a discussion period of two weeks, though I would prefer to actually start the vote Sunday 00:00:00 UTC (on November 23th, or, if the DPL desires to shorten the discussion period, november 16th). (BTW, I am a huge fan of these embedded spreadsheets) |+---+---+---+---| || 1 | 2 | 3 | 4 | |+---+---+---+---| | Robert Millan <[EMAIL PROTECTED]>| 1 | 1 | 1 | | | Bas Wijnen <[EMAIL PROTECTED]> | 1 | | | | | Manoj Srivastava <[EMAIL PROTECTED]> | 1 | 1 | | | | Holger Levsen <[EMAIL PROTECTED]> | 1 | 1 | 1 | 1 | | Peter Samuelson <[EMAIL PROTECTED]> | 1 | 1 | 1 | | | Hubert Chathi <[EMAIL PROTECTED] | 1 | 1 | 1 | | | Andreas Barth <[EMAIL PROTECTED]>| | | | 1 | | Alexander Reichle-Schmehl <[EMAIL PROTECTED]> | | | | 1 | | Reinhard Tartler <[EMAIL PROTECTED]> | | | | | | Bernd Zeimetz <[EMAIL PROTECTED]> | | | | 1 | | Neil McGovern <[EMAIL PROTECTED]> | | | | 1 | | Frans Pop <[EMAIL PROTECTED]> | | 1 | 1 | | | [EMAIL PROTECTED] (Rémi Vanicat) | 1 | 1 | 1 | 1 | |+---+---+---+---| || 7 | 7 | 6 | 6 | |+---+---+---+---| #+TBLFM: $2=vsum(@[EMAIL PROTECTED])::$3=vsum(@[EMAIL PROTECTED])::$4=vsum(@[EMAIL PROTECTED])::$5=vsum(@[EMAIL PROTECTED]) The ballot and wml for the vote web pages should now be drafted by the sponsors, to be put into place by the secretary team. manoj ,[ Proposal 1: reaffirm the Social Contract ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that we promised to deliver a 100% free operating system | (Social Contract #1); | | 3. Given that we have known for two previous releases that we have | non-free bits in various parts of Debian, and a lot of progress has | been made, and we are almost to the point where we can provide a | free version of the Debian operating system, we will delay the | release of Lenny until such point that the work to free the operating | system is complete (to the best of our knowledge as of 1 November 2008). ` ,[ Proposal 2: allow Lenny to release with proprietary firmware ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` ,[ Proposal 3: (allow Lenny to release with DFSG violations ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress on DFSG compliance | issues; however, they are not yet finally sorted out; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the packages distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat fixing of DFSG violations as | a best-effort process. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` ,[ Proposal 4 ] | Debian's priorities are our users and free software. We don't trade | them against each other. Howe
Re: DFSG violations in Lenny: new proposal
Hi, With a new option added to the list, the discussion period is extended again, by a week, starting 10 Nov 2008 21:28:29. The proposals, tentatively, as reproduced below. |+---+---+---+---+---| || 1 | 2 | 3 | 4 | 5 | |+---+---+---+---+---| | Robert Millan <[EMAIL PROTECTED]>| 1 | 1 | 1 | | | | Bas Wijnen <[EMAIL PROTECTED]> | 1 | | | | | | Manoj Srivastava <[EMAIL PROTECTED]> | 1 | 1 | | | 1 | | Holger Levsen <[EMAIL PROTECTED]> | 1 | 1 | 1 | 1 | | | Peter Samuelson <[EMAIL PROTECTED]> | 1 | 1 | 1 | | | | Hubert Chathi <[EMAIL PROTECTED] | 1 | 1 | 1 | | | | Andreas Barth <[EMAIL PROTECTED]>| | | | 1 | | | Alexander Reichle-Schmehl <[EMAIL PROTECTED]> | | | | 1 | | | Reinhard Tartler <[EMAIL PROTECTED]> | | | | | | | Bernd Zeimetz <[EMAIL PROTECTED]> | | | | 1 | | | Neil McGovern <[EMAIL PROTECTED]> | | | | 1 | 1 | | Frans Pop <[EMAIL PROTECTED]> | | 1 | 1 | | | | [EMAIL PROTECTED] (Rémi Vanicat) | 1 | 1 | 1 | 1 | | | "John H. Robinson, IV" <[EMAIL PROTECTED]> | | | | | 1 | | Lars Wirzenius <[EMAIL PROTECTED]>| | | | | 1 | | Damyan Ivanov <[EMAIL PROTECTED]> | | | | | 1 | | Colin Tuckley <[EMAIL PROTECTED]> | | | | | 1 | |+---+---+---+---+---| || 7 | 7 | 6 | 6 | 6 | |+---+---+---+---+---| #+TBLFM: $2=vsum(@[EMAIL PROTECTED])::$3=vsum(@[EMAIL PROTECTED])::$4=vsum(@[EMAIL PROTECTED])::$5=vsum(@[EMAIL PROTECTED])::$6=vsum(@[EMAIL PROTECTED]) ,[ Proposal 1: reaffirm the Social Contract ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that we promised to deliver a 100% free operating system | (Social Contract #1); | | 3. Given that we have known for two previous releases that we have | non-free bits in various parts of Debian, and a lot of progress has | been made, and we are almost to the point where we can provide a | free version of the Debian operating system, we will delay the | release of Lenny until such point that the work to free the operating | system is complete (to the best of our knowledge as of 1 November 2008). ` ,[ Proposal 2: allow Lenny to release with proprietary firmware ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress in the kernel firmware | issue; most of the issues that were outstanding at the time of the | last stable release have been sorted out. However, new issues in the | kernel sources have cropped up fairly recently, and these new issues | have not yet been addressed; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the kernel distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat removal of sourceless | firmware as a best-effort process, and deliver firmware as part of | Debian Lenny as long as we are legally allowed to do so. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` ,[ Proposal 3: (allow Lenny to release with DFSG violations ] | 1. We affirm that our Priorities are our users and the free software | community (Social Contract #4); | | 2. We acknowledge that there is a lot of progress on DFSG compliance | issues; however, they are not yet finally sorted out; | | 3. We assure the community that there will be no regressions in the | progress made for freedom in the packages distributed by Debian | relative to the Etch release in Lenny (to the best of our knowledge | as of 1 November 2008); | | 4. We give priority to the timely release of Lenny over sorting every | bit out; for this reason, we will treat fixing of DFSG violations as | a best-effort process. | | (Since this option overrides the SC, I believe it would require 3:1 | majority) ` ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ] | Debian's priorities are our users and fr
