Re: More 5 november in the release schedule

* Emilio Pozuelo Monfort [161108 16:01]: > It is true for other removals from testing, which can happen in two different > ways: > > - The package was removed from unstable > - The package was hinted for testing removal by the release team > > Since britney doesn't enforce

Re: Bug#837606: general: system freeze

[Please do not CC me, I am subscribed. You seem to have a habit of CC'ing the individuals to whose messages you are responding. This is contrary to this list's documented policy.] * Abou Al Montacir [160914 05:31]: > The duty of the project is to > help him

Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)

* Simon McVittie [160727 20:04]: > On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote: > > Shouldn't this > > dependency only be declared at some other level (libdbus, GDBus,...)? > > I think this would have to be a new dbus-session metapackage, unless > I'm missing

preferred form for modification (was: Bug#817092: this browserified)

[please do not CC me] * Ian Jackson <ijack...@chiark.greenend.org.uk> [160711 11:17]: > Marvin Renich writes ("Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: > this browserified"): > > One fundamental purpose... > > I have no idea why you th

Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: this browserified

* Ian Jackson <ijack...@chiark.greenend.org.uk> [160711 08:59]: > Marvin Renich writes ("Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: > this browserified"): > > I have to disagree with this. The requirement for "preferred form of > > modification

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

* german...@ya.ru [160710 23:08]: > Now I want to know if Debian Stable can in some extreme cases, like in > this case with btrfs, replace not_very_good kernel module that is > shipped with its current kernel with a kernel module from other (older > or newer) version of Linux

Re: [Pkg-javascript-devel] Bug#817092: Bug#817092: this browserified

* Jonas Smedegaard [160711 07:08]: > Quoting Pirate Praveen (2016-07-11 10:30:59) > > On Sun, 10 Jul 2016 19:41:17 +0200 Jonas Smedegaard wrote: > > > The requirement of source format of redistributed code is not about > > > it being possible/easy to edit by those

Re: Fingerprint-GUI?

* Andrew Shadura [160507 17:27]: > Fingerprint readers are insecure, and that's something that can't be > fixed. I'd prefer to see fewer fingerprint-related software packages > in Debian rather than more. I cringe when I see blanket statements like this from security

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

* Tollef Fog Heen <tfh...@err.no> [151208 04:33]: > ]] Marvin Renich > > I set Acquire::Pdiffs::FileLimit "3"; and have been much happier. Why > > this (or something near this) wasn't the default from the start, I don't > > know. The current default is an ex

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

* Vincent Danjean [151208 03:17]: > Le 06/12/2015 13:01, David Kalnischkies a écrit : > > You can't update individual indexes at the moment. The question is why > > you would want to as from my point of view that was a pretty annoying > > technical detail that I had to run

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

* David Kalnischkies <da...@kalnischkies.de> [151208 07:36]: > On Tue, Dec 08, 2015 at 10:32:52AM +0100, Tollef Fog Heen wrote: > > ]] Marvin Renich > > > * Tollef Fog Heen <tfh...@err.no> [151207 00:17]: > > > > ]] David Kalnischkies > > >

Re: Upcoming version of apt-file - using apt-acquire and incompatibilities

* Tollef Fog Heen [151207 00:17]: > ]] David Kalnischkies > > > [And before someone complains about PDiff being slow in apt based on > > some years old experience: The PDiff handling was changed nearly two > > years ago… – and apt-file was using PDiffs before already, so no real

Re: service failures should not fail dpkg installation

* Paul Gevers <elb...@debian.org> [150924 14:12]: > Hi > > On 24-09-15 18:21, Henrique de Moraes Holschuh wrote: > > On Thu, 24 Sep 2015, Marvin Renich wrote: > > What we really want is a "do not fail upgrade, BUT report that some services > > *that were

service failures should not fail dpkg installation [was: Re: promoting virtualbox-dkms to virtualbox pre-depends]

* Jeroen Dekkers <jer...@dekkers.ch> [150924 07:23]: > At Wed, 23 Sep 2015 13:53:11 -0400, > Marvin Renich wrote: > > I think it should be documented in the developers reference that if you > > attempt to start or restart a service in postinst, you should guard

Re: promoting virtualbox-dkms to virtualbox pre-depends

* Ritesh Raj Sarraf [150923 07:47]: > On Wed, 2015-09-23 at 13:23 +0200, Ansgar Burchardt wrote: > > Gianfranco Costamagna writes: > > > the problem actually is that virtualbox-dkms should be configured > > > *before* configuring virtualbox > > >

Re: promoting virtualbox-dkms to virtualbox pre-depends

* Ritesh Raj Sarraf [150923 04:06]: > Adding Moritz from the DSA. > > On Tue, 2015-09-22 at 19:59 +0200, Julien Cristau wrote: > > On Tue, Sep 22, 2015 at 15:00:35 +, Gianfranco Costamagna wrote: > > > > > As shown in policy 7.2 > > > > > > "You should not specify a

Re: promoting virtualbox-dkms to virtualbox pre-depends

* Marvin Renich <m...@renich.org> [150923 07:52]: > What might work, ..., and then use dpkg triggers to start the > vbox service after all packages in the dpkg installation run have been > configured. If I understand correctly how dpkg triggers work, this could cause a restart

Re: promoting virtualbox-dkms to virtualbox pre-depends

[please do not CC me; I am subscribed] * Ritesh Raj Sarraf [150923 11:50]: > Okay!! But, btw, can someone enlighten the use case for Pre-Depends ?? If you need to use something from another package in your preinst script, you will need a Pre-Depends. For example, cron

Re: promoting virtualbox-dkms to virtualbox pre-depends

* Ritesh Raj Sarraf [150923 12:54]: > > Each call to dpkg will cause the triggers to be run, so if > > apt(itude) happens to separate the vbox and vbox-dkms installations > > into separate runs of dpkg, vbox might be restarted the first time > > with the wrong module, but it will

Re: Security concerns with minified javascript code

* Bas Wijnen <wij...@debian.org> [150902 17:36]: > > On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich <m...@renich.org> wrote: > > > No, "A preferred form" is what upstream uses. The DFSG does not use > > > the term "THE preferred form", a

Re: Security concerns with minified javascript code

* Neil Williams <codeh...@debian.org> [150902 14:15]: > On Wed, 2 Sep 2015 13:14:31 -0400 Marvin Renich <m...@renich.org> wrote: > > It is presumed that upstream already has what it considers "source"; > > in the case of this thread, that is minified JS. >

Re: Security concerns with minified javascript code

the tools to build it are also in main. I also said that this is a hard problem to tackle, but Debian should tackle it (which is what this thread appears to be doing) instead of ignoring it. > On Wed, 2 Sep 2015 13:33:57 -0400 Marvin Renich <m...@renich.org> wrote: > > This whole thre

Re: Security concerns with minified javascript code

* Ben Hutchings [150902 10:12]: > My preferred form is a git repository of code written in C, Python, or > some other language I know. That doesn't mean that a tarball of > Haskell code is non-free! I can't tell whether you are agreeing or disagreeing with me! > The

Re: Security concerns with minified javascript code

* Neil Williams [150902 10:22]: > Upstream is another recipient of code distributed under copyleft. > Having changes in a format which upstream can use is absolutely a > sensible and sane criterion for what is regarded as the form of the > code for modification. To do

Re: Security concerns with minified javascript code

* Thorsten Glaser [150902 07:50]: > There is (I just had an epiphany) another possible criterium to apply > for to determine what the preferred form of modification is: ^ for [Okay, so I'm being pedantic, but this is a common

Re: Security concerns with minified javascript code

* Raphael Hertzog [150901 12:57]: > Because we have alternative "compilers" (aka minifier) available to > recreate another minified file thas should work just as well. No. Debian does not allow you to ship a compiled C program that was compiled elsewhere; the maintainer or a

Re: Security concerns with minified javascript code

> On Mon, Aug 31, 2015 at 11:21:55AM -0400, Marvin Renich wrote: > > * Bas Wijnen <wij...@debian.org> [150830 07:53]: > > > On Sun, Aug 30, 2015 at 10:14:13AM +0200, Vincent Bernat wrote: > > > > Is that the preferred form of modification? It depends, but

Re: Security concerns with minified javascript code

First, let me make it clear that I am firmly in the camp that believes minified JS cannot be distributed in main unless the tools to recreate it are also in main. It bothers me that there appears to be a not-insignificant number of people with upload rights who do not believe this. This message

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

* Joachim Breitner nome...@debian.org [150823 07:24]: With pow-priority, you mean one that does not get shown by default? But is that much better than allowing the interested admin to change the configuration afterwards? Actually, I was thinking it should be similar to postfix, which looks

Re: Bug#796529: ITP: local-apt-repository -- Ready to use local apt repository

* Joachim Breitner nome...@debian.org [150822 09:04]: Hi Jakub, Am Samstag, den 22.08.2015, 14:54 +0200 schrieb Jakub Wilk: * Joachim Breitner nome...@debian.org, 2015-08-22, 13:58: With this package installed, every Debian package (i.e. a *.deb file) dropped into

Re: Metapackage dependencies: Depends or Recommends?

* Neil Williams codeh...@debian.org [150729 03:30]: I'd still use Depends in the metapackage. e.g. foo-server has lots of strict dependencies without which is simply won't install or start. foo-client has less dependencies and a few Recommends because the client can work for a range of

Re: Metapackage dependencies: Depends or Recommends?

* Josh Triplett j...@joshtriplett.org [150729 17:18]: Ole Streicher wrote: Other packages will never depend on this metapackage; they will rather depend on the individual programs. Other packages *in Debian* will not. I actually build a pile of personal metapackages to set up systems,

Re: Metapackage dependencies: Depends or Recommends?

* Andreas Tille andr...@an3as.eu [150729 04:14]: On Tue, Jul 28, 2015 at 10:51:02AM -0700, Russ Allbery wrote: I'm sure this is personal taste, and in the end it won't matter for most people (except folks who don't install Recommends, but they're going to break their system regardless),

Re: Metapackage dependencies: Depends or Recommends?

* Simon McVittie s...@debian.org [150728 08:55]: On 28/07/15 13:08, Marvin Renich wrote: There is no downside to using Recommends and no upside to using Depends for metapackages. I don't think it's that simple; it comes down to a question of what the metapackage means, which is a design

Re: Metapackage dependencies: Depends or Recommends?

* Ole Streicher oleb...@debian.org [150728 05:15]: Hi, I recently created two metapackages (astromatic and eso-pipelines) which were accepted by the ftp-masters yesterday. However, I got a commend that my choice of Recommends dependencies is discouraged: Paul Richards Tagliamonte

Re: Proposal v2: enable stateless persistant network interface names

* Marco d'Itri m...@linux.it [150625 07:27]: On Jun 25, Martin Pitt mp...@debian.org wrote: Unlike /dev nodes, network interfaces can't have aliases as far as I know. Am I missing anything? No. As is usual with udev, the people who do not understand how it works are always ready to

Re: Proposal: enable stateless persistant network interface names

* Marco d'Itri m...@linux.it [150510 23:55]: I see a large enough consensus about switching by default to ifnames, and I believe that the few people who want MAC-based names for USB interfaces can easily set NamePolicy=mac or write a custom rule. Huh? This thread seems to have lots of

Re: Proposal: enable stateless persistant network interface names

* Martin Pitt mp...@debian.org [150509 05:27]: TBH, hotpluggable USB network adapters which change all the time sound like a corner case in a server world where you have hand-written config files referring to interface names. They are of course common on the client side, but there stable

Re: Proposal: enable stateless persistant network interface names

* Josh Triplett j...@joshtriplett.org [150509 17:37]: Marvin Renich wrote: I disagree that stable interface names do not matter for USB adaptors for consumer laptops. I have owned two laptops where the on-board WiFi adaptor was too new to have reliable Linux drivers until 6-12 months

Re: motd handling in jessie

* Josh Triplett j...@joshtriplett.org [150126 11:24]: Russ Allbery wrote: Josh Triplett j...@joshtriplett.org writes: However, I don't think run a pile of scripts to write out a dynamic MOTD at boot time is a sensible default, either. Why not? I'd suggest putting update-motd

Re: DE features dependent on Systemd

* Matthias Urlichs matth...@urlichs.de [141130 09:22]: But on a multi-user system, we can't depend on the first user being any sort of special owner; it might just as well be the person whose desk the machine is hidden under I strongly disagree with this. The person performing the

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

* Ansgar Burchardt ans...@debian.org [140909 11:16]: On 09/09/2014 16:59, Russ Allbery wrote: I don't believe we should switch init systems on upgrade without at least a prompt, I think there are good arguments for both switching to the new default and not: Perhaps, but not without

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

* Mathieu Parent math.par...@gmail.com [140909 09:15]: 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez clo...@igalia.com: [...] So, when upgrading from Wheezy to Jessie, we have three options: 1) Keep the user init system (sysvinit most probably) 2) Upgrade to systemd after asking

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

* Michael Biebl bi...@debian.org [140909 11:43]: Am 09.09.2014 17:15, schrieb Ansgar Burchardt: Having only some systems switch to a different init system on upgrade seems potentially confusing to me. Agreed. We definitely should switch the machines on upgrades. There is a good reason why

Re: let's split the systemd binary package

* Tollef Fog Heen tfh...@err.no [131024 15:06]: ]] Marvin Renich I believe that systemd/GNOME upstream is intentionally coupling the two in order to force adoption of systemd. You're aware that GNOME and systemd upstreams are two completely distinct groups with (AFAIK) very little

Re: let's split the systemd binary package

* Tollef Fog Heen tfh...@err.no [131024 05:39]: ]] Steve Langasek On Thu, Oct 24, 2013 at 02:21:25AM +0200, Matthias Klumpp wrote: 2013/10/24 Steve Langasek vor...@debian.org: [...] If Gnome depends on gnome-settings-daemon, which now depends on systemd, this might be a

Re: Have NetworkManager disabled by default when...

* Michael Biebl bi...@debian.org [120718 17:31]: On 18.07.2012 22:54, Matt Zagrabelny wrote: Why are people not a aware of that update-rc.d interface? Is this a general documentation problem? I've been under the impression that future upgrades to the package would re-enable the

Re: Migration path for 'Multi-Arch:allowed' packages

* Ben Hutchings b...@decadent.org.uk [120613 23:56]: On Wed, 2012-06-13 at 12:47 +0100, Wookey wrote: I added a user-oriented HOWTO to the multiarch doc-collection last month as there seemed to be a shortage of such docs to point to that weren't cryptic specifications, or talking mostly

Re: RFC: OpenRC as Init System for Debian

* Thomas Goirand z...@debian.org [120511 04:45]: On 05/11/2012 04:04 AM, David Weinehall wrote: From: http://en.wikipedia.org/wiki/Configuration_file In computing, configuration files, or config files configure the initial settings for some computer programs. They are used for user

Re: RFC: OpenRC as Init System for Debian

* Steve Langasek vor...@debian.org [120511 16:17]: On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote: The FHS is very specific that /etc is for *Host-specific* system No, this is a total retcon. When the FHS was written, this was definitely NOT a shared understanding

Re: Multiarch file overlap summary and proposal

* Russ Allbery r...@debian.org [120214 01:48]: If this is comprehensive, then I propose the following path forward, which is a mix of the various solutions that have been discussed: I thought Goswin's suggestion in [1] of having dpkg use implicit diversions has merit and deserves further

Re: directory under /usr/bin -- Ok or not?

* Stig Sandbeck Mathisen s...@debian.org [07 09:55]: Josselin Mouette j...@debian.org writes: We already have $pkglibdir and $pkgdatadir for those. There is no technical need for a new directory in /usr, and it doesn’t improve anything for users. Possibly not for the users, but it

Re: / vs. /usr vs. fsck(8)

* Holger Levsen hol...@layer-acht.org [111014 07:49]: On Donnerstag, 13. Oktober 2011, brian m. carlson wrote: If / and /boot are the same filesystem, then using a filesystem that the bootloader supports is important. At least in the recent past, grub 2 didn't support booting off ext4;

Re: aptitude weirdness wrt upgrades and keeps

* Miles Bader mi...@gnu.org [111014 03:04]: Paul Wise p...@debian.org writes: Not a solution for the interactive mode, or am I wrong? Not AFAICT, I only read the documentation rather than the code though. Kinda surprising, actually; this has long been the #1 most horrible thing about

Re: Writing to /etc/ from a privileged UI

* David Paleino da...@debian.org [110509 04:19]: On Mon, 9 May 2011 11:12:53 +0200, Adam Borowski wrote: /etc may include only _static_ configuration. What you have is variable state which belongs in /var. It's no different from a database, or dpkg's status data. Static IPs, DNS

Re: Default size limits for /run (/var/run) and /run/lock (/var/lock)

* Luca Capello l...@pca.it [110414 06:43]: Hi there! Disclaimer: this is my last post on this matter (i.e. the meaning of RAMLOCK), it seems there is a problem with myself or my understanding. Either I do not read `man rcS` as you read it or we do not understand each other, so here the

Re: potential MBF: first alternate depends not available in main

* Carsten Hey cars...@debian.org [110304 06:17]: * Paul Wise [2011-03-04 12:54 +0800]: Debian Policy section 2.2.1 already covers this: ...the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package.

Re: potential MBF: first alternate depends not available in main

* Scott Kitterman deb...@kitterman.com [110304 10:01]: Seems reasonable to me. Bug filed: #616462 ...Marvin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Re: UPG and the default umask

* Bastien ROUCARIES roucaries.bast...@gmail.com [100520 08:30]: reopen 315089 thanks Closed by maintener and reopened, if we use libpam for umask it could be even raised to RC critical, so please correct this behavior, report upstream. I agree that it could be misleading for other distro in

Re: APT do not work with Squid as a proxy because of pipelining default

* Robert Collins robe...@robertcollins.net [100517 22:03]: Given that pipelining is broken by design, that the HTTP WG has increased the number of concurrent connections that are recommended, and removed the upper limit - no. I don't think that disabling pipelining hurts anyone - just use a

Re: APT do not work with Squid as a proxy because of pipelining default

* Goswin von Brederlow goswin-...@web.de [100518 02:53]: Marvin Renich m...@renich.org writes: Documenting this problem somewhere that an admin would look when seeing the offending Hash sum mismatch message would also help. Turning off pipelining by default for everybody seems like

Re: UPG and the default umask

* Reinhard Tartler siret...@debian.org [100517 08:56]: Let's have a look at the source. Note that options-usergroups is set iff the option usergroups is used. ,[modules/pam_umask/pam_umask.c] | /* Set the process nice, ulimit, and umask from the |password file entry. */ | static

Re: UPG and the default umask

* Aaron Toponce aaron.topo...@gmail.com [100517 13:05]: On 05/17/2010 10:49 AM, Harald Braumann wrote: from pam_umask's description of the usergroups option: If the user is not root, and the user ID is equal to the group ID, *and* the username is the same as primary group name, the umask

Re: APT do not work with Squid as a proxy because of pipelining default

* Robert Collins robe...@robertcollins.net [100517 17:42]: Due to the widespread usage of intercepting proxies, its very hard, if not impossible, to determine if a proxy is in use. Its unwise, at best, to assume that no proxy configured == no proxy processing your traffic :(. -Rob IANADD,

Re: The 'git' Debian package in squeeze

* Gerrit Pape p...@smarden.org [090917 05:18]: Hi, thanks to Ian Beckwith, the GNU Interactive Tools package 'git' has been renamed to 'gnuit' in lenny. In lenny 'git' is a transitional package that depends on gnuit, in squeeze and sid there's no 'git' package anymore. I'm about to

Re: The 'git' Debian package in squeeze

* Leandro Doctors ldoct...@gmail.com [090917 10:41]: 2009/9/17 Marvin Renich m...@renich.org: But, if I were a gnuit user and not a git-core user, I would find it annoying (and possibly confusing) when upgrading from lenny to squeeze to have a new package added that I didn't want

Re: The 'git' Debian package in squeeze

* Vincent Danjean vdanjean...@free.fr [090917 11:05]: There is no way APT (or dpkg) knows that git/lenny should be remove instead of being 'upgraded' in git/squeeze. Note that adding a release (squeeze) without a git package will not solve the problem: the git/lenny package will not be

Re: The 'git' Debian package in squeeze

* Marvin Renich m...@renich.org [090917 11:40]: I do not know how aptitude deals with the automatic/manual flag in this case, though. Suppose a user has etch installed with git 4.3.20-10 (marked as manual in aptitude). The upgrade to lenny will bring in gnuit 4.9.4-1; I think aptitude

Re: Change user used by package

* Harald Braumann ha...@unheit.net [090113 16:49]: On Tue, 13 Jan 2009 12:57:11 -0800 Steve Langasek vor...@debian.org wrote: If they remove the user on purge, that should be changed anyway. Well, jabber-common does remove the user jabber on purge, jabberd2, though, doesn't. And it seems

Re: Change user used by package

* Harald Braumann ha...@unheit.net [090113 05:47]: Hi, I'd like to package mu-conference 0.7 (multi-user chat component for jabber). The version currently in Debian (jabber-muc 0.6.0) uses the user ``jabber'', which is created by jabber-common, on which jabber-muc depends. The new

Re: Change user used by package

(I'm subscribed, no need to CC me.) * Jamin W. Collins jcoll...@asgardsrealm.net [090114 14:09]: I'm not subscribed, haven't been following the lists for a while. The old package should probably be removed completely in favor of the new. That's fine. I didn't know the state of jabber-muc,

Re: RFC: update-rc.d script disable|reenable

* Michael Biebl [EMAIL PROTECTED] [080924 02:09]: If you rename all symlinks to K??, as the patch does, you will get such a behaviour. I.e. when you boot your system, the service will not be started automatically. It also won't be stopped or started when you change a runlevel, even if you

Re: RFC: update-rc.d script disable|reenable

* Michael Biebl [EMAIL PROTECTED] [080922 14:43]: Kel Modderman wrote: Hi all, This email describes an extension of update-rc.d to provide an interface for disabling and reenabling initscript sysvinit runlevel start links. Hi again, thinking more about it, I think a function

Re: Not stopping daemons, where are we?

* Peter Samuelson [EMAIL PROTECTED] [080705 02:37]: [Marvin Renich] If the package does need to save state, don't enable the quick halt option! The maintainer definitely ought to know this. Why are all of you talking as though sending SIGTERM were not the standard way to tell a process

Re: Not stopping daemons, where are we?

* Bernd Eckenfels [EMAIL PROTECTED] [080703 09:57]: In article [EMAIL PROTECTED] you wrote: The Debian maintainer for a specific VPN decides it does not need special shutdown handling Nono, thats not my point. My point is, that a maintainer of any package cannot easyly forsee which part

Re: Not stopping daemons, where are we?

* Bernd Eckenfels [EMAIL PROTECTED] [080701 20:45]: In article [EMAIL PROTECTED] you wrote: I mean the pending-write case is the most obvious. But what about resolver caches, VPNs and the like? What kind of data loss do you expect to arise from shutting down a VPN client without giving

Re: QUESTION: Debian Policy: Manual pages

* Ian Jackson [EMAIL PROTECTED] [080224 09:18]: Bas Zoetekouw writes (Re: QUESTION: Debian Policy: Manual pages): Why a recommends? In order to satisfy the spirit of policy (every binary must have a man page) it would need to be a depends, imo. I think the point of policy is to ensure the

Re: ${shlibs:Depends} results libfamin0 or libfam0?

* Andrew Lee [EMAIL PROTECTED] [080129 06:09]: Dear folks, I am working on pcmanfm package. It has build-depends on 'libgamin-dev', but somehow the binaries packages depends on 'libfam0'. I checked 'libgamin-dev' depends on 'libgamin0', but I don't know why the binaries packages are not

Re: adding user to package-forreign group

* Micha Lenk [EMAIL PROTECTED] [071129 17:27]: [snip] But prior to releasing the package I am seeking for feedback here, whether that really is a good idea. Is there anything that I missed? Is it okay to mess around with other package's group memberships? Any other comments? Please give

Re: What to do when the LaTeX sources are missing, but an XML equivalent was rewritten from scratch ?

* Norbert Preining [EMAIL PROTECTED] [071119 17:28]: [liberally snipped] And it matters to me that people can get optimal typographic quality. So either we have to distribute crippled versions of many documents, crippled only in the sense that yes, all the information/text is there, but

Re: using testing/stable/unstable names with cdebootstrap

* Goswin von Brederlow [EMAIL PROTECTED] [071008 05:46]: Ritesh Raj Sarraf [EMAIL PROTECTED] writes: Hi, Is there a reason to not use stable/testing/unstable as the names in config/suites file ? Currently it only has code names like etch/lenny/sid. Ritesh Does it matter

Re: kydpdict relationships

* Manoj Srivastava [EMAIL PROTECTED] [070724 21:05]: If we are going to transition to installing Recommends by default in lenny, I would say go with the Recommends, since it caters to more users. Or else, use Depends, but that makes the system less efficient for those of

Re: adding desktop files to misc packages

* Josselin Mouette [EMAIL PROTECTED] [070725 06:10]: Le mercredi 25 juillet 2007 à 00:14 -0500, Manoj Srivastava a écrit : The latter might be fine as a local policy; but surely is not correct as a Debian default. We should make it _possible_ to implement a local policy of hiding

Re: adding desktop files to misc packages

* Josselin Mouette [EMAIL PROTECTED] [070725 12:57]: Le mercredi 25 juillet 2007 à 08:54 -0400, Marvin Renich a écrit : Gnome and KDE are targeted primarily at desktop users, not servers. If, as a desktop user, I install a graphical app on my machine, I *expect* to see that app in the main

Re: adding desktop files to misc packages

* Frank Küster [EMAIL PROTECTED] [070725 10:08]: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 03:17:51PM +0200, Frank Küster [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 08:54:40AM -0400, Marvin Renich [EMAIL PROTECTED

Re: Proposed new POSIX sh policy, version two

* Jari Aalto [EMAIL PROTECTED] [061123 06:56]: But for the shells there are. I think the Policy should exempt shells and require that if package is not POSIX/Susv -compiant, it needs to announce dependance on a particular shell -- where it bash, tcsh, pdksh ..., if it uses those shells

Re: ITP: subtitleeditor -- Graphical subtitle editor with sound waves representation

* Peter Samuelson [EMAIL PROTECTED] [060812 14:00]: No need to mention the competitors, really. I strongly disagree. While an individual upstream author may have competitive feelings towards other software that provides similar functionality, one of Debian's primary priorities is its users

Re: texlive-basic_2005-1_i386.changes REJECTED

* Norbert Preining [EMAIL PROTECTED] [051128 11:20]: Dear all! Please comment, not only on the package naming, but also on the bin-to-source mapping. texlive-documentation-source 57M Reasoning: The documenatation is actually in a specific language, so we

<    1   2