he
ass, so they won't try it again :P)
I firmly believe that fixing the problems with testing (mainly
testing-security at this point in time) would be MUCH better than
dropping testing and freezing unstable before the next release.
--
Gergely Nagy
they won't try it again :P)
>
> What's the problem? If you feel bored, go to #debian-bugs and help
> fixing RC bugs. We could have a BSP every three days or so. There you
> will have semi-social contact and can motivate each other to do the
> actual work.
...and that can be done with testing in place, with all the benefits it
provides.
So far, the main complaint against testing is that sometimes packages
get stuck. *Duh*, so fix the problem that made them stuck. That might
need some social engineereing, as most of the time, stuckage is not
caused by technical problems. Would you want to push the same larger
update into a frozen unstable, you'd run into the very same problems
anyway.
--
Gergely Nagy
So, from my point of view, there aren't too many architectures.
Actually, the fact that Debian runs on so many architectures is in the
top five reasons I'm a Debian user.
--
Gergely Nagy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Tue, 2005-03-08 at 16:22 -0800, Steve Langasek wrote:
> Hi Gergely,
>
> On Wed, Mar 09, 2005 at 12:56:10AM +0100, Gergely Nagy wrote:
> > Just to chime in, not saying that maintaining a consistent state between
> > architectures is an easy thing and presents no problems,
o not
want to upload a new, probably half-broken dpatch just to orphan it.
--
Gergely Nagy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ke the
> > package alone.
>
> I am also interrested in being a part of it. What about
> making a project on alioth like we did for fetchmail?
It is already there, and has been from day 1. We didn't use the stuff
provided by alioth though... Mostly the arch repo was in use, an
l agression, one still needs a thick
enough skin (although, a bit thinner as otherwise) to deal with
occassional agression originating from outside (be that a bug report, a
Debian or linux-flaming article somewhere on the net, etc), preferably
calmly, without having ones blood pressure rise to unh
On Tue, 2005-01-25 at 12:02 -0600, John Hasler wrote:
> Gergely Nagy writes:
> > Indeed. Even if all of us start to behave ourselves and avoid nasty
> > flamewars (ha! in your dreams! :P), we still have to deal with the
> > occassional bugreporter of Barbaric Communication S
> does anyone knows a solution to let packages FTBFS on
> buildd's which architecure are not supported by the
> software?
If the arch is not supported by the package, why is it in the packages
Architecture: line to begin with?
--
Gergely Nagy
--
To UNSUBSCRIBE, email to [E
epend on libc. It is a base package,
> but still listed as a dependency.
Furthermore, as adduser is used in preinst, the package must Pre-Depend
on it (according to my reading of Policy 7.2).
--
Gergely Nagy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
gs with only new entries posted to -devel (or
even -d-a) would be much better.
I fall into the "doesn't read WNPP summaries because they're too
friggin' long" category, but I'd certainly glance through them, would
they be shorter and posted to a list I'm su
On Fri, 2005-05-27 at 14:17 +0300, Cesar Martinez Izquierdo wrote:
> El Viernes 27 Mayo 2005 14:09, Pierre Habouzit escribió:
> > multimedia seems more appropriate. most of the video player actually are
> > music player too, and some music player can show video with appropriate
> > plugins (xmms e.
On Fri, 2005-05-27 at 07:38 -0400, Roberto C. Sanchez wrote:
> On Fri, May 27, 2005 at 01:26:59PM +0200, Gergely Nagy wrote:
> > On Fri, 2005-05-27 at 14:17 +0300, Cesar Martinez Izquierdo wrote:
> > > El Viernes 27 Mayo 2005 14:09, Pierre Habouzit escribió:
> > &
On Fri, 2005-05-27 at 14:00 +0200, Philipp Kern wrote:
> Gergely Nagy wrote:
> > Then media players are just fine in graphics or sound, depending on
> > which is their main focus (or they could even be in gnome or kde, or
> > whatever).
>
> Please see it from a user&#x
On Fri, 2005-05-27 at 14:13 +0200, Pierre Habouzit wrote:
> Le Vendredi 27 Mai 2005 14:00, Philipp Kern a écrit :
> > Gergely Nagy wrote:
> > > Then media players are just fine in graphics or sound, depending on
> > > which is their main focus (or they could even b
ready.
Thanks in advance,
Gergely Nagy
--
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
the debian/ part of their packages under
> > revision control.
>
> Please also look in .svn/deb-layout for a line like:
>
> origDir=/home/inet/debian/dev/tarballs
>
> That would be the most probable location for the orig tarball.
Done in the arch repo, thanks!
For inte
"
`
And so on... This also allows C-style commands which is also a plus in
my book.
Please help us testing this release, by giving it a go, and
checking if it does not break existing functionality or if there are
more features wanted[3]!
Cheers,
--
Gergely Nagy
[1] http://www
> * Michael Ablassmeier ([EMAIL PROTECTED]) [031201 19:55]:
> > I think, at least Packages like "dpkg" or "gnupg" should call
> > "dh_md5sums". I was wondering, if it would be usefull to make
> > a mass bug-filling against these Packages. Before, it would be
> > nice to have a List of Packages (may
ed against the correct
package? That'd result in your buggetting automatically closed when the
bug is fixed in the other package, it would probably make filtering
easier too, and the bug would normally appear on the bug page of your
package, so users would notice it and won't report it ag
Hi!
Some time ago, I assembled a list of packages which were arch: all,
yet used binary-arch to build the package, and another list of
packages whose debian/copyright did not have a pointer to the full
license.
Unfortunately, I wasn't able to file the bugs at that time, so I redid
the test now. S
> >> Rather than mass filing bugs, can you write a lintian check for it
> >> instead?
> >
> > He filed a bug about Upstream Author(s), I fixed it, and then shaleh and
> > others reverted it >:)
> >
>
> I think we have better things to be nitpicky about. Besides, lintian tries to
> only enforce
> On Tue, Aug 20, 2002 at 05:56:58PM +0200, Gergely Nagy wrote:
> > Some time ago, I assembled a list of packages which were arch: all,
> > yet used binary-arch to build the package, and another list of
> > packages whose debian/copyright did not have a pointer to the full
>
Package: lintian
Version: 1.20.17
Severity: wishlist
Tags: patch
> Rather than mass filing bugs, can you write a lintian check for it
> instead?
As promised, here is the check:
diff -u -urNad old/copyright-file new/copyright-file
--- old/copyright-file 2002-08-20 23:04:54.0 +0200
+++ ne
kage in Debian does that...
--
Gergely Nagy
If the source includes SHA, then it must remain in non-US, together
with the binaries (iow: binaries compiled without SHA, from a source
which has SHA in it must be in non-us still).
At least, that's what I think, but I may be wrong.
--
Gergely Nagy \ mhp/|8]
pgpJ5XuclYybE.pgp
Descri
Hello!
> Maintainer: Eric Delaunay <[EMAIL PROTECTED]>
> Changed-By: Eric delaunay <[EMAIL PROTECTED]>
^
These are not the same, note the case...
Cheers,
--
Gergely Nagy \ mhp/|8]
pgpzmOMLrgPk3.pgp
Description: PGP signature
You can either Cc: debian devel, or add a X-Debbugs-Cc: header (works
like Cc, but includes the bug# in the subject too).
IIRC, it is documented somewhere in the doc-debian package.
Cheers,
--
Gergely Nagy \ mhp/|8]
pgpWqyKFvBmI9.pgp
Description: PGP signature
thing like that..
Cheers,
--
Gergely Nagy \ mhp/|8]
pgpS3dP2SXClJ.pgp
Description: PGP signature
> I can see where a patch.diff might come in. It may not always be the
> result of a DD not cleaning out the debian/ directory before building.
> It may even be an essential part of the build process.
Yes, but probably with a more suitable name.. (note that I checked the
patch.diff itself, and it
> I mailed the maintainer of the above package on the eleventh of december and
> haven't got a reply yet. All the bugs of the package are pretty old, a new
> version of the proggy is also available upstream, current version is > a year
> old.
He is my applicant, and has a new version ready (wit
> Is there anyone out there who actually appreciates the storms of
> "Information received" acks that debbugs generates? If not, it is
> fairly simple to turn them off - we just need to decide to do so.
I do. If lists are slow, I get an ACK back quickly, and won't wonder
for hours if my mail got
Package: wnpp
Severity: wishlist
Owner: Gergely Nagy
* Package name: adderall
Version : 0.1.2
Upstream Author : Gergely Nagy
* URL : https://github.com/algernon/adderall
* License : LGPL
Programming Lang: Hy
Description : a miniKanren implementation
Daniel Dickinson writes:
> On 10/09/14 02:52 PM, Noel Torres wrote:
>>
>> Yes. Why to install OpenVPN which might not work? aptitude will tell you
>> that
>> they are not coinstallable and the sysadmin will then have the option of
>> switching init system to a non default one, knowing what th
> "David" == David L Craig writes:
David> On 14Nov10:2325+0900, Charles Plessy wrote:
>> With most of the work done on topic mailing lists, trolls lose the lever
effect
>> they have when feasting on debian-devel or debian-vote. Let's make our
project
>> stronger by reducing
>>>>> "David" == David L Craig writes:
David> On 14Nov10:2154+0100, Gergely Nagy wrote:
>> You do realize topic lists are public too, right?
David> Yes, but most Debian users don't even know about
David> them nor do they need to sin
> "Raphael" == Raphael Hertzog writes:
Raphael> Packaging branches and tags
Raphael> ===
[...]
Raphael> The Git repository listed in debian/control's `Vcs-Git` field
should
Raphael> usually have its HEAD point to the branch corresponding to the
R
> "Jonathan" == Jonathan Dowland writes:
Jonathan> On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote:
>> Personally I wouldn't use anything other than debian-only repos, at
>> least for those where I have a choice. I also actively avoid
>> contributing to packages that
>>>>> "Raphael" == Raphael Hertzog writes:
Raphael> Hi Gergely,
Raphael> On Wed, 12 Nov 2014, Gergely Nagy wrote:
Raphael> When releasing a Debian package, the packager should create and
push
Raphael> a signed tag named `/`. For exam
> "Cameron" == Cameron Norman writes:
>>> OK, so the system has syslog-ng installed. For what ever reason
>>> syslog-ng
>>> is not starting automatically, but starts manually by systemctl.
>>
>>> syslog-ng version 3.5.6-2
>>> systemd version 215-5+b1
>>
>> M
> "Cameron" == Cameron Norman writes:
Cameron> Apparently this is a known issue, and another person has
experienced
Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426
>>
>> That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are
>> closel
Andreas Noteng writes:
> Hello, in one of my packages I have multiple files paragraphs with
> license GPL-2+, at the end I have a standalone license paragraph labeled
> GPL-2, this generates a lintian warning about missing license paragraph
> GPL-2+. Shouldn't lintian ignore the +, because it onl
Igor Pashev writes:
> I wonder no one mention Solaris SMF :-)
Does a free port of that thing exist, which we could use?
--
|8]
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://list
Riku Voipio writes:
> On Thu, May 03, 2012 at 01:23:29PM +0200, Stefano Zacchiroli wrote:
>> 3) public, but contributors-only list
>
>> This has been implemented by other FOSS projects. A notable example is
>> Ubuntu who have a split between ubuntu-devel (project members only +
>> whitelisting)
Stefano Zacchiroli writes:
> 2) "don't feed the troll" + report abuses to listmasters and act
>accordingly
Of the three, this is the least disruptive, in my opinion. Of course,
all the problems you mention (social awkwardity, effort from the
community and extra burden on listmasters) apply,
Michael Gilbert writes:
> On Mon, May 7, 2012 at 11:55 AM, Michael Gilbert wrote:
>> Would it be unreasonable if someone were to start an
>> "uncommon-licenses" package? Then any package depending on that could
>> use a reference to the license instead of including the full text in
>> debian/cop
Patrick Lauer writes:
> On 05/08/12 00:04, Marco d'Itri wrote:
>> On May 07, Ben Hutchings wrote:
>>
>>> Means that services can be started (and stopped?) in response to events
>>> such as hardware discovery, incoming network connections, the status of
>>> other services, and so on. (With depen
Stephan Seitz writes:
> On Mon, May 07, 2012 at 03:30:11PM +0100, Ben Hutchings wrote:
>>(lots of options, you get to keep the pieces when they break), but some
>>of us are trying to make Debian better than that. We don't need more
>>half-assed options, we need a solution.
>
> Well, it seems we
Thomas Goirand writes:
> On 05/08/2012 12:53 AM, Gergely Nagy wrote:
>> FWIW, Debian provides a couple of init systems already, and has been for
>> as long as I can remember. You certainly have the option to choose.
>>
> Sure, we have the init replacement packages, bu
Joey Hess writes:
> Gergely Nagy wrote:
>> debian/$package.docs:
>> | #! /usr/bin/dh-exec --with=copyright-magic
>> | debian/copyright.in | copyright-magic
>> | README.md
>> | whatever-else-you want
>
> On the off chance this is not another long-delayed Apr
Stefan Fritsch writes:
> On Monday 07 May 2012, Gergely Nagy wrote:
>> > well, that's another 10 lines of shell worst case. We haven't
>> > agreed on how exactly to handle it and make it configurable and
>> > stuff (especially as tools like monit cover th
(Please try to respect M-F-T, and not Cc: me. If I want a CC, I'll set
M-F-T appropriately, thanks)
Stefan Fritsch writes:
> On Tue, 8 May 2012, Gergely Nagy wrote:
>>> but sometimes it is necessary to do unusual things in init scripts to
>>> properly intregrate a se
Philipp Kern writes:
> On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote:
>> > And the integrator/packager may not want to learn all the funny
>> > languages that daemons can be written in (ocaml, haskell, java, ruby,
>> > ...). Besides, init scripts are
Tollef Fog Heen writes:
> ]] Philipp Kern
>
>> You will not, however, get a conffile update prompt when the system
>> file changes (e.g. to update your own local copy to incorporate the
>> fix).
>
> This is something I'm pondering if we should handle in either a systemd
> trigger or a tool that
Sven Joachim writes:
> On 2012-05-09 14:01 +0200, Gergely Nagy wrote:
>
>> Philipp Kern writes:
>>
>>> On Wed, May 09, 2012 at 10:39:38AM +0200, Gergely Nagy wrote:
>>>> > And the integrator/packager may not want to learn all the funny
>>>
Uoti Urpala writes:
> Roger Leigh wrote:
>> Can't we just do things the Debian way, and just provide them directly
>> as conffiles in /etc? It's nice that systemd provides its mechanism
>> to symlink/include the units provided elsewhere, but is this either
>> necessary or desirable on a Debian s
Uoti Urpala writes:
> Gergely Nagy wrote:
>> Uoti Urpala writes:
>> > Not having the files in /etc by default does have technical advantages.
>> > It's easier to see what is local non-default configuration. Original
>> > default file is always availa
Steve McIntyre writes:
> Uoti Urpala wrote:
>>
>>Who's the one choosing his preferred configuration format based on the
>>limitations of his preferred packaging system here? Hint: it's not Red
>>Hat.
>
> *yawn*
>
> When you've got something constructive to add to Debian development,
> let us know
Don Armstrong writes:
> On Thu, 10 May 2012, Uoti Urpala wrote:
>> Don Armstrong wrote:
>> > The reason why it is relevant is because [...]
>>
>> I don't see how the following would make this comparison with rpm
>> relevant.
>
> This is debian-devel, and we're talking about configuration file
>
Don Armstrong writes:
> On Thu, 10 May 2012, Gergely Nagy wrote:
>> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
>> do something *very* close to what etc-overrides-non-etc does. To the
>> point that changing a file under /etc/default, or adding a snip
Thomas Goirand writes:
> On 05/11/2012 12:53 AM, Uoti Urpala wrote:
>> The reason why most old applications do not follow that approach (at
>> least not yet) is pretty obvious: their authors never considered it.
>> etc-overrides-lib semantics have only become a seriously considered
>> alternative
Tollef Fog Heen writes:
> ]] Uoti Urpala
>
> Hi,
>
>> Wrong: as mentioned in this thread before, one of the advantages of the
>> etc-overrides-lib model is the option of having a file in /etc that
>> first includes the one in /lib, then overrides just one particular
>> value. This allows handlin
Philip Hands writes:
> On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala
> wrote:
>> Marco d'Itri wrote:
>> > On May 10, Bjørn Mork wrote:
>> >
>> > > Agree. Copying a large set of default policies into /etc just because
>> > > they *can* be overridden is not user friendly. And it does not ma
Thomas Goirand writes:
> 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 applications,
> server processes and operating system settings."
>
> The fact
Tollef Fog Heen writes:
> ]] Gergely Nagy
>
>> Tollef Fog Heen writes:
>>
>> > ]] Uoti Urpala
>> >
>> > Hi,
>> >
>> >> Wrong: as mentioned in this thread before, one of the advantages of the
>> >> etc-overrides-
Stephan Seitz writes:
> On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote:
>>Are you happy with dropping a snippet into a conf.d/ directory, and your
>>software breaking on an upgrade without notice? Because that can happen
>>even now, with software that uses only
m...@linux.it (Marco d'Itri) writes:
> On May 11, Gergely Nagy wrote:
>
>> And in etc-overrides-lib, config files still remain in /etc. Its just
>> the defaults that live elsewhere. That the defaults are files, and are
>> under /lib, is an implementation detail,
Stephan Seitz writes:
> On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:
>>Neither the FHS, nor the policy says anything about etc-overrides-lib as
>>far as I can see. Neither pro or con. Do feel free to point me to the
>>relevant section, would I be mistaken
Steve McIntyre writes:
> Jean-Christophe Dubacq wrote:
>>
>>If dpkg kept a copy of the original configuration file (to be retrieved
>>at all times), it would be easier to spot local changes.
>>I use etckeeper to do that, but it's a bit tiresome to isolate all local
>>changes (I have to save the d
Thomas Goirand writes:
> On 05/11/2012 04:52 PM, Gergely Nagy wrote:
>> Neither the FHS, nor the policy says anything about etc-overrides-lib as
>> far as I can see. Neither pro or con. Do feel free to point me to the
>> relevant section, would I be mistaken.
>>
Thomas Goirand writes:
> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>>In other words, it does *exactly* the same thing systemd is
>>criticised for.
>>
>
> Which doesn't mean that it's a good practice.
Tell me what you would gain, if there were no
Thomas Goirand writes:
> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>> Long story short, I still don't see what the fuss is about.
>>
> The fuss is about we're being told that there will be silent
> overwriting of configuration files without being prompted abo
Thomas Goirand writes:
> Seriously, can't someone who broke his configuration wget the package,
> and use mc to get into the .deb and get the original configuration
> file???
FWIW, I'd love an easier way to keep track of my /etc, where upstream
changes and my own are on a separate branch. So the
m...@linux.it (Marco d'Itri) writes:
> On May 11, Thomas Goirand wrote:
>
>> > Long story short, I still don't see what the fuss is about.
>> The fuss is about we're being told that there will be silent
>> overwriting of configuration files without being prompted about
>> changes, which potential
Thomas Goirand writes:
> On 05/11/2012 08:33 PM, Michael Biebl wrote:
>> Am 11.05.2012 14:30, schrieb Marco d'Itri:
>>
>>> The problem with etc-overrides-lib is that a file must be copied in
>>> full from /lib to /etc to be modified, and then future changes to the
>>> same file in /lib will
SEEWEB - Marco d'Itri writes:
> But this is a user error. The point is that with etc-overrides-lib there
> is no prompt at all when the upstream configuration changes.
Bzzt. There's no prompt ever when upstream defaults change. Unless *all*
the defaults are laid out in /etc, *AND* the user modi
Thomas Goirand writes:
> On 05/11/2012 11:08 PM, Marvin Renich wrote:
>> For clarity, the etc-overrides-non-etc model that I am talking about is
>> where the file in /etc can override individual values, not where the
>> file in /etc must replace the entirety of the non-etc configuration.
>>
>
Tollef Fog Heen writes:
> ]] Gergely Nagy
>
>> Tollef Fog Heen writes:
>>
>> > ]] Gergely Nagy
>
>> >> In that case, the including file can be changed (by the admin) to be a
>> >> separate file, that does not include, and get the usual co
Thomas Goirand writes:
> On 05/12/2012 03:29 AM, Gergely Nagy wrote:
>> It's not etc-overrides-lib that is the problem. It's defaults changing
>> without notice that is.
>
> Then, let me ask this:
> Do you expect that systemd's default in /lib will change
Thomas Goirand writes:
> On 05/12/2012 03:19 AM, Gergely Nagy wrote:
>> It's perfectly able to notice changes
>> in /lib/systemd too, or pretty much anywhere else.
>>
> I thought these were only default which we shouldn't
> have to care about?!? :)
You
Josselin Mouette writes:
> Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
>> Thomas Goirand writes:
>> > The fact that these files are in /lib and shouldn't be touched by the admin
>> > doesn't make them less configuration files. They still
Josselin Mouette writes:
> Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit :
>> > There is a huge difference between gconf, for which you can set one
>> > specific setting in /etc, overriding the default in /usr (and in a way
>> > that will not break
Chris Knadle writes:
> On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote:
>> On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote:
>> > On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote:
>> > > No, I hereby start saying good by to 3.0
>> >
>> > I'm hoping we can revi
"Daniel Leidert" writes:
> Hi,
>
> Our bug tracker contains items for packages, which do (not longer)
> exist. What should happen to them? I see, that it might be a good idea
> to keep them for the case, a package is re-introduced. But this might
> happen only for a few packages. Most of them got
Thomas Goirand writes:
> By the way, do other think that, even in this case, I should keep the
> changes
> as minimum as possible? Or is it ok, considering that all of our
> toolsets have
> changed since the last upload (eg: we now have pkg-php-tools and dh 8
> sequencer), that we do a bit more c
Bernd Zeimetz writes:
> Which bad things happened that we have to change the current process?
As far as I see, it's more about "what good things didn't happen" why we
have to change the process.
That is also addresses a few corner cases that could've gone bad, but
never did is a side-effect.
-
Ian Jackson writes:
> So for example, DDs have enormous theoretical power but there are
> strong and well documented social controls on how they should exercise
> that. I think as a matter of principle that the same principle should
> apply to DMs: it is easy to remove a misbehaving DM from Uplo
Gregor Jasny writes:
> When one tries to fix a FTBFS bug a look into the upstream VCS is
> often helpful. Sometimes a link to browse them is easily found on the
> homepage linked from the PTS page. But often these links are deeply
> buried in the linked website.
>
> What I'd like to see in the De
Thomas Goirand writes:
> On 06/15/2012 12:03 AM, Cyril Brulebois wrote:
>> Anyway, here's what I've been doing for our 150+ X packages:
>>
>> $ cat xserver-xorg-video-ati.git/debian/watch
>> #git=git://anongit.freedesktop.org/xorg/driver/xf86-video-ati
>> version=3
>> http://xorg.freedesktop.org
Ansgar Burchardt writes:
> On 06/15/2012 11:33 AM, Thomas Goirand wrote:
>> Yeah, a hook of any sorts is ok for me. The get-vcs-source in debian/rules
>> seems quite ok to me. Should debcheckout be modified to call it? It's part
>> of devscript, do you think it's ok if I submit a wishlist bug rep
"Theodore Ts'o" writes:
> P.S. One of the things I'm thinking about doing is writing a script which
> automatically generates the debian/patches directory from the git
> repository. So when I specify the base release (i.e., v1.42.4), it will
> do something like git format-patch, but in a debian/
"Eugene V. Lyubimkin" writes:
> On 2012-07-10 15:32, Josselin Mouette wrote:
>> Le mardi 10 juillet 2012 à 17:38 +0900, Miles Bader a écrit :
>> > What's wrong with Recommends: in that case? It seems to perfectly
>> > match the "makes life easier for > > XXX>" scenario you describe.
>>
>> Reco
"Eugene V. Lyubimkin" writes:
> On 2012-07-10 16:18, Gergely Nagy wrote:
>> But the purpose of the meta-package is to pull stuff in. Depends does
>> that, Recommends does not, therefore Recommends is not appropriate for
>> the task.
>
> Surely Recomm
"Eugene V. Lyubimkin" writes:
> On 2012-07-10 18:10, Jonas Smedegaard wrote:
>> The very purpose of a meta-package is to _ensure_ that a certain set of
>> packages is installed, not just recommend them: All (not only most)
>> users of that package need all its dependencies satisfied
>
> My defi
Sune Vuorela writes:
> On 2012-07-10, Gergely Nagy wrote:
>> No. Only if installing recommends is turned on, which cannot be
>> guaranteed.
>
> There is many ways to break your system. turning off installation of
> recommends is one of them.
During the past ~14 year
Nikolaus Rath writes:
> Gergely Nagy writes:
>> But, to cut the story short, attached to this mail is a script you can
>> use to take any metapackage, and remove (or demote) any of its
>> dependencies. It echoes a control-file thingy, combining it with equivs
>> is
Nikolaus Rath writes:
> Gergely Nagy writes:
>> For the cases where one wants to have most of the stuff installed that
>> the meta-package would pull in, but not all, solutions already exist.
>
> What solutions do you mean?
Installing the pieces one wants by hand, for one.
"Eugene V. Lyubimkin" writes:
> Moreover, despite me understanding the picture, I still
> has no clean, safe and documented way to do what I'd want in case the
> package maintainer chosed Depends.
You have: install the pieces you want by hand. That's at least clean and
safe. I do not think it is
Henrique de Moraes Holschuh writes:
> IMO, metapackages should "depend" on the absolutely required stuff (and many
> times that will be the empty set), "recommend" the rest, and maybe even
> "suggest" fringe packages. This achieves maximum usability for more
> usecases, and malfunctions only in
Andrei POPESCU writes:
> On Ma, 10 iul 12, 18:43:03, Gergely Nagy wrote:
>>
>> During the past ~14 years I've been using Debian with that setting
>> turned off, nothing ever broke on my systems because of this setting. If
>> it does, then I'll consider t
1 - 100 of 246 matches
Mail list logo
