On Wed, 18 Mar 2009 00:26:30 -0500
Manoj Srivastava wrote:
> On Tue, Mar 17 2009, Neil Williams wrote:
>
> >> Do you prevent mixing old and new .debs and .tdebs?
> >
> > Changes to translations use +t1.diff.gz etc.
> >
> >> How do you merge data from a new package into the tdeb data?
> >
> > T
Stephen Gran writes:
>> Users must not be in specific groups to access hardware, this is broken
>> and insecure.
>
> That's the first I've heard that argument - of course you don't give
> untrusted users access to hardware, but we've always managed access to
> devices with group membership (lp, d
On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
> >> Given that we already have a tool that can download upstream
> >> sources, with or without mangling, and can be used by facilities
> >> outside of the unpacked Debian source package to determine if there was
> >> new
On Mon, Mar 16, 2009 at 11:38:50AM -0500, Manoj Srivastava wrote:
> I am opposed to bloating the policy with dictum that are
> unnecessary, but I see your point about the API. The API is essentially
> the watch file, and we already specify that in the policy. DEHS (as
> mentioned in pol
Hector Oron writes:
> Hello Goswin et al,
>
> IMHO, the things you are talking about are quite nice. They way it
> works sounds to me a little complex, that it is very close to the idea
> of crosscompiling, as the *right way*, as opposed to accumulate dirty
> hacks and workarrounds that it is w
On Tue, 17 Mar 2009, Manoj Srivastava wrote:
> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
> > It seems to me that you are indeed close, but with the exception of
> > this required include in all our debian/rules, which will be a PITA to
> > achieve.
>
> Modulo debhelper, cdbs, et.al ca
Raphael Hertzog writes:
> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > achieve.
>>
>>
Le Wed, Mar 18, 2009 at 07:25:40AM +, Neil Williams a écrit :
>
> Maintainers will be creating TDebs in Squeeze+1, using debian/rules,
> using debhelper calls and uploading TDebs each time they would
> currently upload any package that contains /usr/share/locale/LC_*/ etc.
> Those TDebs are, e
On Wed, 18 Mar 2009 19:13:03 +0900
Charles Plessy wrote:
> Le Wed, Mar 18, 2009 at 07:25:40AM +, Neil Williams a écrit :
> >
> > Maintainers will be creating TDebs in Squeeze+1, using debian/rules,
> > using debhelper calls and uploading TDebs each time they would
> > currently upload any pa
On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> I also included DEB_VENDOR in the set of variables. This variable is not
> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
> to become more used in the future for things like this:
> - enable additional patch/features dependin
On Tue, Mar 17, 2009 at 03:03:22PM +, Simon Huggins wrote:
> Is there a reason you need this now and can't wait until you've managed
> to argue for the shared library from upstream and cajoule them into
> producing a .so?
> I had an upstream that wasn't very confident with soname changes and
>
Hi,
the following X input drivers will be removed from the archive soon
unless someone steps up to maintain them (both upstream and in Debian).
If you use one of these, now is the time to make yourself known.
magellan
calcomp
digitaledge
dmc
elo2300
dynapro
jamstudio
magictouch
palmax
spaceorb
te
Loïc Minier wrote:
> On Wed, Mar 18, 2009, Raphael Hertzog wrote:
>> I also included DEB_VENDOR in the set of variables. This variable is not
>> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
>> to become more used in the future for things like this:
>> - enable additiona
* Adeodato Simó [Tue, 17 Mar 2009 18:25:10 +0100]:
> * Raphael Geissert [Mon, 16 Mar 2009 18:32:51 -0600]:
> > > Removing GNOME from testing because something depends on libfrufru1 isn't
> > > a win for testing's usability.
> > It would only last until it is able to migrate without breaking anyt
Hi,
I reported approximately 6 bugs, which where actually RFP. I reported
those as wishes, not as RFP.
For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241
Can I change it? How?
\r
--- Begin Message ---
On Wed, Mar 18, 2009 at 11:34:37AM +0100, rosea wrote:
> Package: minicomp
Hi
Dne Wed, 18 Mar 2009 12:40:42 +0100
Grammostola Rosea napsal(a):
> I reported approximately 6 bugs, which where actually RFP. I reported
> those as wishes, not as RFP.
> For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241
>
> Can I change it? How?
At least this bug has bee
Grammostola Rosea wrote:
Hi,
I reported approximately 6 bugs, which where actually RFP. I reported
those as wishes, not as RFP.
For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241
Can I change it? How?
\r
-
On Wed, Mar 18, 2009 at 8:18 PM, Julien Cristau wrote:
> the following X input drivers will be removed from the archive soon
> unless someone steps up to maintain them (both upstream and in Debian).
> If you use one of these, now is the time to make yourself known.
Should debian-user and forums.
Hello,
there are missing licenses in some source files in upstream project
I'm packaging for Debian.
There is just license in the "main" source file.
Is it fine?
Or should I edit these files and add missing licenses (copy & paste
from "main" file)?
Thanks for advice.
Dominik Smatana
--
To
On Wed, 18 Mar 2009, Loïc Minier wrote:
> If you implement conditional behavior in your rules, typically based on
> lsb_release -is output:
> if vendor is Ubuntu:
> foo
> elif vendor is Debian:
> bar
> you face a problem when you meet:
> else:
>
> What behavior should one use here?
On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> Of course an Ubuntu derivative could be surprised if they get
> a Debian-variant of a package instead of an Ubuntu-variant…
Yes, that's exactly the issue I'm raising
> I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> describe pa
Quer ter independência financeira? Quer ter uma boa fonte de renda
alternativa? Está procurando emprego?
Conheça o Projeto Renda Familiar, um trabalho criado para promover e
restaurar o poder de compra das pessoas, através de um trabalho moderno,
dinâmico e eficaz.
Link do projeto: http://www.p
On Wed, Mar 18, 2009, Emilio Pozuelo Monfort wrote:
> There is a good use case for this that doesn't require a conditional, which is
> passing --with-package-name=$(DEB_VENDOR) to configure for packages that have
> this option (e.g. the GStreamer stack, that right now checks
> lsb_release -si outpu
* Enrico Zini [Wed, 18 Mar 2009 11:42:58 +]:
> On Tue, Mar 17, 2009 at 03:03:22PM +, Simon Huggins wrote:
> > Is there a reason you need this now and can't wait until you've managed
> > to argue for the shared library from upstream and cajoule them into
> > producing a .so?
> > I had an u
On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> > if vendor is Ubuntu:
> > foo
> > elif vendor is Debian:
> > bar
> > you face a problem when you meet:
> > else:
> >
> > What behavior should one use here?
>
> Debian should always be the "else" because it's the default case. It
> ensur
Package: wnpp
Severity: normal
I would like to give up maintaining this package.
Probably someone who takes up ecasound.
Package: ecamegapedal
Priority: optional
Section: sound
Installed-Size: 2032
Maintainer: Junichi Uekawa
Architecture: amd64
Version: 0.4.4-7
Depends: libasound2 (>> 1.0.14), l
Package: wnpp
Severity: normal
I'd like someone to pick this package up. I used to use this to get
sparc machines installed via netboot. I don't do that anymore.
Package: rarpd
Priority: extra
Section: net
Installed-Size: 104
Maintainer: Junichi Uekawa
Architecture: amd64
Version: 0.981107-7.1
D
Package: wnpp
Severity: normal
I'm looking for someone to pick this package up. I think there has
been a new upstream release since the last packaged version.
Package: ladspa-sdk
Priority: optional
Section: sound
Installed-Size: 240
Maintainer: Junichi Uekawa
Architecture: amd64
Version: 1.1-6
Package: wnpp
Severity: normal
There has been new upstream release of this package. I just haven't
had the time to maintain this package properly.
Package: ecasound
Priority: extra
Section: sound
Installed-Size: 3676
Maintainer: Junichi Uekawa
Architecture: amd64
Source: ecasound2.2
Version: 2
Hi there,
while thinking about how to solve #508189, where I need to change the position
of the initscript in bootorder, I thought it would not sufficient to change
only the call of dh_installinit in the rules file.
If an user changed the symlinks, I guess I will break his changes. How should
Package: wnpp
Severity: normal
I'd like to look for someone who can look after apt-listbugs.
Upstream maintenance is required; knowledge of ruby or the Debian BTS
is a plus.
Package: apt-listbugs
Priority: optional
Section: admin
Installed-Size: 436
Maintainer: Junichi Uekawa
Architecture: all
Hi,
On Mittwoch, 18. März 2009, Grammostola Rosea wrote:
> I reported approximately 6 bugs, which where actually RFP. I reported
> those as wishes, not as RFP.
> Can I change it? How?
see http://www.debian.org/Bugs/Developer
regards,
Holger
signature.asc
Description: This is a digital
* Michal Čihař [2009-03-18 13:20]:
> > those as wishes, not as RFP.
> > For example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520241
> >
> > Can I change it? How?
>
> At least this bug has been already fixed.
I fixed all of them as they came in.
--
Martin Michlmayr
http://www.cyrius.c
On Wed, Mar 18 2009, Raphael Hertzog wrote:
> On Tue, 17 Mar 2009, Manoj Srivastava wrote:
>> On Tue, Mar 17 2009, Stefano Zacchiroli wrote:
>> > It seems to me that you are indeed close, but with the exception of
>> > this required include in all our debian/rules, which will be a PITA to
>> > ach
On Wed, Mar 18 2009, Steve Langasek wrote:
> On Mon, Mar 16, 2009 at 12:08:56AM -0500, Manoj Srivastava wrote:
>> >> Given that we already have a tool that can download upstream
>> >> sources, with or without mangling, and can be used by facilities
>> >> outside of the unpacked Debian so
Steve Langasek wrote:
> It's certainly far *more* insecure to add users to the kmem group than to
> the nvram group.
Definitely.
> But I'm not aware of any reason that users need to access /dev/nvram,
> generally. The only tool I know of that uses this interface is
> hotkey-setup, which runs a d
Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode
* Package name: metatheme-gilouche
Version : 11.1.2
Upstream Author : Jakub Steiner
* URL : http://forgeftp.novell.com/opensuse-art/
* License : GPL-2+
Programming Lang: SVG, XML, gtkrc
Descriptio
On Wed, Mar 18, 2009 at 05:37:49PM +0100, Bernd Zeimetz wrote:
> > But I'm not aware of any reason that users need to access /dev/nvram,
> > generally. The only tool I know of that uses this interface is
> > hotkey-setup, which runs a daemon as root to handle polling the nvram state,
> > so the gr
On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> So according to your rule that policy should standardize "common practice"
> and not mandate something completely new, the env variable proposal is in
> more widespread usage.
For ten years, the "common practice" was that dpkg-buil
On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> For ten years, the "common practice" was that dpkg-buildpackage did not set
> any variable.
>
> We cannot standardize on the "env variable proposal" because such proposal has
> never be made. Instead dpkg-buildpackage was broken in
On Mar 18, Steve Langasek wrote:
> A peek at the source says it uses /proc/acpi/ibm/light.
Other people told me that they believe that nowadays all modern
thinkpads use a kernel driver.
This is the complete list of groups which I'd rather stop using:
fuse (I have no idea about how FUSE work
On Wed, Mar 18, 2009 at 06:23:55PM +0100, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more wi
2009/3/18 Marco d'Itri :
> This is the complete list of groups which I'd rather stop using:
>
> fuse (I have no idea about how FUSE works)
Neither do I, I see FUSE helper binary is set suid, and executable
only for fuse members, but there could be more AFAIK. It would be a
good idea not to mes
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
> On Mar 18, Steve Langasek wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd
Hello,
On Wed, 18 Mar 2009, Bill Allombert wrote:
> On Wed, Mar 18, 2009 at 09:53:46AM +0100, Raphael Hertzog wrote:
> > So according to your rule that policy should standardize "common practice"
> > and not mandate something completely new, the env variable proposal is in
> > more widespread usag
On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
> On Mar 18, Steve Langasek wrote:
>
>> A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
>
> This is the complete list of groups which I'd
Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org
The current maintainer (Frederic) is very busy, I helped out for some time,
but can't really give this quite big package the care it needs either lately.
The package already lives in collab-maint svn, it would be great if
m...@linux.it (Marco d'Itri) wrote:
Hi,
> This is the complete list of groups which I'd rather stop using:
> scanner (do SCSI scanners still exist? how are they used?)
Yes, SCSI scanners still exist, and they're still used through
/dev/sgX. Actually, all high-volume, high-speed scanners are
Bastien ROUCARIES wrote:
> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?
Ack. That's what it the group is use
Bastien ROUCARIES wrote:
Hi,
>> scanner (do SCSI scanners still exist? how are they used?)
>
> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?
Marco is specifical
On Wed, 18 Mar 2009, Marco d'Itri wrote:
> On Mar 18, Steve Langasek wrote:
> > A peek at the source says it uses /proc/acpi/ibm/light.
> Other people told me that they believe that nowadays all modern
> thinkpads use a kernel driver.
A driver which I happen to be the maintainer of ;-)
The drive
On Tue, 17 Mar 2009, Bernd Zeimetz wrote:
> Please do not as it will allow users which need to access Thinkpad-specific
> devices (== /dev/nvram) access to /dev/{mem,kmem,port}. That's a huge security
> hole in my opinion.
Which are? If you mean people running tpb, tpb is as far as I know,
comple
Manoj Srivastava writes:
> Also, any upstream Makefile that sets CFLAGS (don't most ones
> that use automake do that?) will also be not affected, unless even more
> hackery is done. At this point, what dpkg does to these variables not
> enough to justify any such effort.
Most packages
Raphael Hertzog writes:
> I can understand you were not happy with the way the change was done but
> saying dpkg-bp is broken is strong (and wrong). If you really believed
> that a major mistake was done at that time, you could have complained
> louder and you could have asked for a tech-ctte rul
On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
wrote:
> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
>> On Mar 18, Steve Langasek wrote:
>>
>>> A peek at the source says it uses /proc/acpi/ibm/light.
>> Other people told me that they believe that nowadays all modern
>> thinkpads use
On Wed, 2009-03-18 at 21:51 +0900, Paul Wise wrote:
> On Wed, Mar 18, 2009 at 8:18 PM, Julien Cristau wrote:
>
> > the following X input drivers will be removed from the archive soon
> > unless someone steps up to maintain them (both upstream and in Debian).
> > If you use one of these, now is th
Manoj Srivastava schrieb:
> On Mon, Mar 16 2009, Raphael Hertzog wrote:
>
>> On Sun, 15 Mar 2009, Bill Allombert wrote:
>>> There is no documented semantic for CFLAGS et. al. in Debian policy. While
>>> some Makefile handle it in a certain way, this is not mandatory in
>>> any way. For example so
On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
wrote:
> On Wed, Mar 18, 2009 at 7:23 PM, Bastien ROUCARIES
> wrote:
>> On Wed, Mar 18, 2009 at 7:13 PM, Marco d'Itri wrote:
>>> On Mar 18, Steve Langasek wrote:
>>>
A peek at the source says it uses /proc/acpi/ibm/light.
>>> Other people
Raphael Hertzog schrieb:
> On Wed, 18 Mar 2009, Loïc Minier wrote:
>> If you implement conditional behavior in your rules, typically based on
>> lsb_release -is output:
>> if vendor is Ubuntu:
>> foo
>> elif vendor is Debian:
>> bar
>> you face a problem when you meet:
>> else:
>>
>>
Julien BLACHE wrote:
> m...@linux.it (Marco d'Itri) wrote:
>
> Hi,
>
>> This is the complete list of groups which I'd rather stop using:
>
>> scanner (do SCSI scanners still exist? how are they used?)
>
> Yes, SCSI scanners still exist, and they're still used through
> /dev/sgX. Actually, a
Matthias Klose writes:
> Manoj Srivastava schrieb:
>> A) Provide a way to specify project wide defaults for env variables
>> B) Allow a site admin to selectively override these, and provide site
>> wide defaults
>> C) Allow a package to set some flags that would otherwise break the
>>
On Wed, 18 Mar 2009, Matthias Klose wrote:
> > I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> > describe parent relationship, and create a new tool to query those
> > meta-information) but I wonder what impact you expect it would have
> > on the decision of exporting DEB_VEND
Bernd Zeimetz wrote:
Hi,
>> Yes, SCSI scanners still exist, and they're still used through
>> /dev/sgX. Actually, all high-volume, high-speed scanners are
>> SCSI. Some have a USB interface too, but it's slower.
>
> I also know some fancy damn expensive scanners with firewire, but I doubt
> they
Hi there!
On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote:
> On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
> wrote:
>> BTW instead of arguing about group and something like this could we
>> create a wiki page on debian wiki about justification of group.
>> Therefore purpose of ev
On Mar 18, Bastien ROUCARIES wrote:
> Scanner is useful, imagine I work in a company working on a secret
> project. One of the computer has a scanner. Do you wnat to give
> scanning right to the internship student ?
No, I want to give access to the raw scanner device only to its own
driver-daemon
On Thu, Mar 19, 2009 at 12:21 AM, Luca Capello wrote:
> Hi there!
>
> On Wed, 18 Mar 2009 22:16:05 +0100, Bastien ROUCARIES wrote:
>> On Wed, Mar 18, 2009 at 9:38 PM, Bastien ROUCARIES
>> wrote:
>>> BTW instead of arguing about group and something like this could we
>>> create a wiki page on debi
On Mon, Mar 16, 2009 at 02:28:08PM +0100, Steffen Moeller wrote:
> > Would there be support for creating a grid task, and splitting it this way?
> >
> > Currently the packages are in the new queue. Should I wait until they
> > actually reach unstable before creating the task? Are there any other
>
I'd like to chime in with the general concern that the proposal to
remove a bunch of groups from udev seems under-baked and that the
current groups have value.
I definitely would like to see the tss (tpm) group remain along with
the kvm and fuse groups. I think scanner is important as well.
I ca
On Wed, 2009-03-18 at 14:20 +0100, Dominik Smatana wrote:
> Hello,
>
> there are missing licenses in some source files in upstream project
> I'm packaging for Debian.
>
> There is just license in the "main" source file.
>
> Is it fine?
>
> Or should I edit these files and add missing licenses (
69 matches
Mail list logo
