Programming Lang: Go
Description : lex provides support for a *nix (f)lex like tool on
.l sources
Package lex provides support for a *nix (f)lex like tool on .l sources.
This package is on dependency tree of probe-cli
* License : Expat
Programming Lang: Rust
Description : log file highlighter and a drop-in replacement for tail -f
tailspin is a command line tool
for viewing (and `tail`-ing) log files.
It highlights important keywords
to make navigating log files easier.
.
tailspin is fast and
: GPL2+
Programming Lang: Fortran
Description : Convert crystallographic descriptions into HKL F^2
reflection lists
A program that computes structure factors |F^2| for neutrons, x-rays,
and electrons from CIF/CFL/SHX/PCR crystallographic descriptions.
This is useful to compute the
On 2/15/20 10:03 PM, Bernd Zeimetz wrote:
So far I did not find a single upstream that was not able to understand
a sentence like "Hi, my name is foo and I'm the Debian developer who is
maintaining blubb in Debian".
Thats correct. The maintainer for mg attached a new label
20200215 without he
On 2/15/20 3:14 PM, Geert Stappers wrote:
> FWIW Consider to use email address m...@packages.debian.org for it.
>
>[...]
> The idea is that it helps you to explain that you are maintainer
> of the package in Debian. Hope this helps.
So far I did not find a single upstream that was not abl
On Sat, Feb 15, 2020 at 03:00:52PM +0100, Harald Dunkel wrote:
> On 2/15/20 2:44 PM, Peter Silva wrote:
> > fwiw, looking at the repo on github. There are tags. They're
> > just dates, Ideally one would get an idea of what the tags are from
> > upstream, but you could just git clone using a tag.
Package: wnpp
Severity: wishlist
Owner: Saif Abdul Cassim
* Package name: android-platform-system-extras-ext4utils
Version : 1.0.0
Upstream Author : Hans-Christoph Steiner
* URL :
https://anonscm.debian.org/gitweb/?p=android-tools/android-platform-system-extras.git
*
iPhoneから送信
2017/10/08 午前11:38、ひろき のメッセージ:
>
>
> iPhoneから送信
Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof
* Package name: fdroidcl
Version : 0.3.1-1
Upstream Author : Daniel Martí
* URL : https://github.com/mvdan/fdroidcl
* License : BSD-3-clause
Programming Lang: Go
Description : F-Droid desktop
Powered by Cricket Wireless.
-Ellipsoids
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : standard Geo:: ellipsoid a, b, f and 1/f values
Geo::Ellipsoids provides a large number of standard ellipsoid values
useful for calculations such as when determining the distance between
two points on a
Package: wnpp
Severity: wishlist
Owner: Sean Whitton
* Package name: f-el
Version : 0.17.3
Upstream Author : Johan Andersson
* URL : https://github.com/rejeep/f.el
* License : GPL-3+
Programming Lang: Emacs Lisp
Description : Modern API for working
Control: reassign -1 wnpp
On Ma, 05 nov 13, 13:41:00, Folkert van Heusden (Hackerspace Gouda) wrote:
> Package: f-irc
>
> > Subject: RFP: f-irc -- an irc-client for the console/terminal
Please note that RFP bugs should be filed against the wnpp
pseudo-package (I already took care
Your message dated Sat, 20 Jul 2013 15:37:42 +0800
with message-id
and subject line Re: Bug#717390: general: Issue with sudo apt-get -f install to
fix broken package
has caused the Debian Bug report #717390,
regarding general: Issue with sudo apt-get -f install to fix broken package
to be
have tried running sudo apt-get -f install as well as Synaptic
fix broken packages, but they both want to remove the Retroshare installation.
At present I am at a loss as to what to do, as I need to install clamav and I
have not been able to find a solution.
-- System Information:
Debian Release
Luke Cycon writes:
> I have the added issue that GNOME seems to (somehow) manage to spawn in
> excess of 100 Xserver when I try to log in.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650183
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe".
On Fri, 8 Jun 2012 16:15:42 +0900
Norbert Preining wrote:
> Hi everyone,
>
> is this only me or do I have the feeling that we are going down
> the trench with Gnome?
> Repeatedly:
> - first login: nautilus segfaults in libnautilus-fileroller.so
> after log out and log in it sometimes works
>
On Sun, Jun 10, 2012 at 12:01:12PM -0400, Stephen Allen wrote:
> On Sat, Jun 09, 2012 at 08:38:42PM +0200, Jerome BENOIT wrote:
> > Is Cinnamon detributed within Debian ?
>
> No not last time I checked. It's availabe from LMDE (LinuxMintDebian)
> and since that distro works with Debian testing sou
On Sat, Jun 09, 2012 at 09:27:05PM +0200, Roland Mas wrote:
> Stephen Allen, 2012-06-09 13:54:17 -0400 :
>
> [...]
>
> > +100 On that. Anyone that thinks 2 was better doesn't know much --
>
> There's no call for that belittling.
You're right, poor choice of words. My apologies. ;-D
> > What
On Sat, Jun 09, 2012 at 08:38:42PM +0200, Jerome BENOIT wrote:
> Hello List:
>
> On 09/06/12 19:54, Stephen Allen wrote:
> >
> >+100 On that. Anyone that thinks 2 was better doesn't know much -- What
> >most are saying is they liked the layout better (I think). In that case
> >Cinamon is a good ch
On 09/06/12 21:27, Roland Mas wrote:
> here, but everything I've felt and read and heard is that the primary
> focus of Gnome is no longer "everyone" but "users doing basic tasks",
> and "users trying to be productive" (ie maximize the bandwidth of the
> human-computer interface) are an afterthough
On 06/08/2012 09:15 AM, Norbert Preining wrote:
Hi everyone,
is this only me or do I have the feeling that we are going down
the trench with Gnome?
Repeatedly:
- first login: nautilus segfaults in libnautilus-fileroller.so
after log out and log in it sometimes works
starting it manually mo
On Fri, Jun 08, 2012 at 02:26:23PM +0200, Florian Reitmeir wrote:
> Norbert Preining wrote:
> >is this only me or do I have the feeling that we are going down
> >the trench with Gnome?
> > ...
> >Is this a joke? Are we going to release that in June/July/whenever?
> i use gnome too, and for me its
Stephen Allen, 2012-06-09 13:54:17 -0400 :
[...]
> +100 On that. Anyone that thinks 2 was better doesn't know much --
There's no call for that belittling.
> What most are saying is they liked the layout better (I think). In
> that case Cinamon is a good choice; best of both worlds.
For wha
Hello List:
On 09/06/12 19:54, Stephen Allen wrote:
On Fri, Jun 08, 2012 at 02:26:23PM +0200, Florian Reitmeir wrote:
Norbert Preining wrote:
is this only me or do I have the feeling that we are going down
the trench with Gnome?
Repeatedly:
- first login: nautilus segfaults in libnautilus-file
On Fri, Jun 08, 2012 at 02:26:23PM +0200, Florian Reitmeir wrote:
> Norbert Preining wrote:
> >is this only me or do I have the feeling that we are going down
> >the trench with Gnome?
> >Repeatedly:
> >- first login: nautilus segfaults in libnautilus-fileroller.so
> > after log out and log in it
On Fri, Jun 08, 2012 at 08:46:31AM +0100, Neil Williams wrote:
> On Fri, 8 Jun 2012 09:23:41 +0200
> Holger Levsen wrote:
>
> > On Freitag, 8. Juni 2012, Norbert Preining wrote:
> > > Is this a joke? Are we going to release that in June/July/whenever?
> >
> > yeah, the plan is to release wheezy
Il 08/06/2012 09:15, Norbert Preining ha scritto:
Hi everyone,
is this only me or do I have the feeling that we are going down
the trench with Gnome?
Repeatedly:
- first login: nautilus segfaults in libnautilus-fileroller.so
after log out and log in it sometimes works
starting it manually
Florian Reitmeir writes:
>> Is this a joke? Are we going to release that in June/July/whenever?
> i use gnome too, and for me its working very stable, and gnome3 is way
> better than gnome2.
I installed wheezy to my old laptop a few months ago and was very happy
with gnome too. Maybe the breakage
Norbert Preining wrote:
is this only me or do I have the feeling that we are going down
the trench with Gnome?
Repeatedly:
- first login: nautilus segfaults in libnautilus-fileroller.so
after log out and log in it sometimes works
starting it manually most of the times work, but not always
-
Hi
On Fr, 08 Jun 2012, Holger Levsen wrote:
> yeah, the plan is to release wheezy in June
Thanks for the wise words.
On Fr, 08 Jun 2012, Neil Williams wrote:
> File bugs if not filed already or feed back to existing bugs then fix
> the bugs and we can release.
Done already on several occasi
Hi,
On Freitag, 8. Juni 2012, Neil Williams wrote:
> The freeze will be in June - i.e. this month. The release comes later,
> how much later depends on how many people spend their Debian time
> fixing RC bugs and how many carry on as if the freeze didn't exist.
>
> File bugs if not filed already
On Fri, 8 Jun 2012 09:23:41 +0200
Holger Levsen wrote:
> On Freitag, 8. Juni 2012, Norbert Preining wrote:
> > Is this a joke? Are we going to release that in June/July/whenever?
>
> yeah, the plan is to release wheezy in June
>
s/release/freeze/
The freeze will be in June - i.e. this mon
On Freitag, 8. Juni 2012, Norbert Preining wrote:
> Is this a joke? Are we going to release that in June/July/whenever?
yeah, the plan is to release wheezy in June
.oO( OMFSM. read d-d-a. use the bts and dont rant on -devel. it's useless. )
Hi everyone,
is this only me or do I have the feeling that we are going down
the trench with Gnome?
Repeatedly:
- first login: nautilus segfaults in libnautilus-fileroller.so
after log out and log in it sometimes works
starting it manually most of the times work, but not always
- ssh/gpg agen
For the record: I answered Matthias in a private e-mail, just forgot to CC
-devel, don't know why I didn't use the "answer list" function.
Kind regards,
Kai Wasserbäch
--
Kai Wasserbäch (Kai Wasserbaech)
E-Mail: deb...@carbon-project.org
Jabber (debianforum.de): Drizzt
URL: http://wiki.debia
Package: wnpp
Severity: wishlist
Owner: Mehdi Dogguy
* Package name: f-sharp
Version : 2.0
Upstream Author : Microsoft
* URL : http://www.fsharp.net/
* License : Apache 2.0 License
Programming Lang: F#
Description : Microsoft F# programming language
F
* markus schnalke:
> For exim, this seems to be solved by adjusting the exim configuration:
> ``[...] you might use trusted_users and add uucp to it [...]'' [3].
> See also [4]. It appears that the system administrator has to do the
> change in order to enable uuc
On Feb 22, markus schnalke wrote:
> However, I think the problem could be solved by making the user uucp a
> member of group mail. From my limited POV, this solution represents
> the logic behind: uucp wants to use special facilities of the MTA,
> thus it needs to be in group mail.
This does not
mail to set
the from address (sendmail -f). But the program from hylafax runs as
user uucp.
For exim, this seems to be solved by adjusting the exim configuration:
``[...] you might use trusted_users and add uucp to it [...]'' [3].
See also [4]. It appears that the system administrator has
> Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit :
> >
> > The interface definition behind this is:
>
> That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates
> it is not the interface.
>
[...]
For the sake of
Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit :
>
> The interface definition behind this is:
That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates
it is not the interface.
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUB
Manoj Srivastava writes:
> I think it would be a good idea to _add_ to policy a rule that
> says that "make -f debian/rules" and "./debian/rules" must behave
> identically, to prevent confusion, and to promote reproducibility, and
> conform to
[ I haven't looked the vdr-* source; apologies if I miss something
essential. ]
Tobi wrote:
> Personally I think debian/rules shouldn't be restriked to make.
What happens if you do `./debian/rules -p | less'? Although seldom
needed, that's a useful thing when you have to debug the build syste
On Fri, Oct 30 2009, Tobi wrote:
> Manoj Srivastava schrieb:
>
>> 1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build
>> 2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build
>> 3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build
>> 4. ./debian/rules
Manoj Srivastava schrieb:
1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build
2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build
3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build
4. ./debian/rules SPECIAL_VDR_SUFFIX=devel build
Giving you differing results is confusing enough to
e policy is over specific, but with little
rationale beyond "I think this is so".
I think that
1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build
2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build
3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build
4. ./deb
> Build a standard vdr-plugin-* package:
> dpkg-buildpackage -tc -uc -us -rfakeroot
> Build a development version of the vdr-plugin-* package from the same
> source, but using the API of the development version of VDR and with a
> different binary package name:
> SPECIAL_VDR_SUFFIX=devel dpkg-buil
Michael Tautschnig schrieb:
I think Manoj already explained quite well why policy is that specific about a
single line.
And I explaind why the policy is over specific in this case :-)
The modified shebang line didn't had any drawback in the past and
wouldn't have any drawback in the future.
* Tobi [091030 10:55]:
> From our point of view this is so easy to do and so easy to maintain (it's
> working quite well for over 2 years now), that this very specific
> requirement of the policy just seems to be a useless piece of bureaucratic
> over-specificiation.
That is your point of view. F
[...]
>
> Build a development version of the vdr-plugin-* package from the same
> source, but using the API of the development version of VDR and with a
> different binary package name:
>
> SPECIAL_VDR_SUFFIX=devel dpkg-buildpackage -tc -uc -us -rfakeroot
>
> This way it works out-of-the-box wi
Kalle Kivimaa wrote:
> the special cases are needed? debian/rules is a specific interface for
> Debian building, why are you using that same interface for other
> purposes?
It's just because we believe this is the easiest to use and easiest to
maintain way to do this:
Build a standard vdr-plugin
Tobi writes:
> /usr/share/vdr-dev/dependencies.sh. But the shebang simply is nothing to
> worry about.
May I ask what's the reason you're using this kind of a convoluted
system? Wouldn't it be simpler to separate debian/make-special-vdr.sh
and debian/rules, and call debian/make-special-vdr.sh dir
On Thu, 2009-10-29 at 17:58 -0700, Steve Langasek wrote:
>
> > Not true. If you were not familiar with the special script, you
> would
> > have to read that entire script to understand what it does. OTOH, in
> the
> > make-only approach it is easier to discard the contents of
> > alternate-debian-
On Thu, Oct 29, 2009 at 03:54:23PM +, Matthew Johnson wrote:
> On Thu Oct 29 15:58, Michael Banck wrote:
> > On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> > > Are there any serious objections against just overriding and ignoring
> > > the Linitan warning ab
Manoj Srivastava wrote:
> If I ahve the magic variables set, and call it as
> % make -f ./debian/rules,
> I get the standard behaviour. If I turn around and call it as
> % ./debian/rules,
> I get totally different behaviour.
True but if you DON'T set the
On Thu, 2009-10-29 at 15:54 +, Matthew Johnson wrote:
> On Thu Oct 29 15:58, Michael Banck wrote:
> > On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> > > Are there any serious objections against just overriding and ignoring
> > > the Linitan warning about
t no one has addressed is the wildly different behaviour
that this rules file has when addressed as ./debian/rules and make -f
debian/rules when one has the the "Magic" variables set.
If I ahve the magic variables set, and call it as
% make -f ./debian/rules,
I get the sta
rocedures (i.e. being a Makefile and even make -f compliant).
Personally I think debian/rules shouldn't be restriked to make. But I
know, that changing this has an rather heavy impact, so this is something
completely different from our current problem.
But like Philipp, Lucas or Charles I believ
the first n bytes
of debian/rules despite the interface being completely in accordance with
the normal procedures (i.e. being a Makefile and even make -f compliant).
Lintian's executable-not-elf-or-script speaks about scripts in general but I
don't see anything at first glance that speci
On Thu, Oct 29 2009, Philipp Kern wrote:
> On 2009-10-29, Joerg Jaspert wrote:
>> It is not an overridable error, and I haven't seen any reason yet to
>> convince me to make it one. You do have some reasons, but none I have
>> seen that would not be simple to do in make directly as well.
>>
>> As
On 2009-10-29, Joerg Jaspert wrote:
> It is not an overridable error, and I haven't seen any reason yet to
> convince me to make it one. You do have some reasons, but none I have
> seen that would not be simple to do in make directly as well.
>
> As long as you have those packages wherever, feel f
> Are there any serious objections against just overriding and ignoring
> the Linitan warning about not having "make -f" in the shebang line?
It is not an overridable error, and I haven't seen any reason yet to
convince me to make it one. You do have some reasons, but none I
On Thu Oct 29 15:58, Michael Banck wrote:
> On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> > Are there any serious objections against just overriding and ignoring
> > the Linitan warning about not having "make -f" in the shebang line?
>
> As long as you
On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote:
> Are there any serious objections against just overriding and ignoring
> the Linitan warning about not having "make -f" in the shebang line?
As long as you don't have an objection against having serious bugs filed
and
On Thu, 2009-10-29 at 21:35 +0900, Charles Plessy wrote:
> (The source packages needed the format 3.0 (quilt),
> for which good news are expected soon.)
Already: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457345
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-devel-requ.
Le Thu, Oct 29, 2009 at 08:02:46AM +0100, Michael Tautschnig a écrit :
>
> Debian Policy 4.9 guarantees that the behavior of debian/rules will be the
> same
> if called as either make -f debian/rules or simply debian/rules.
Is there any piece of our infrastructure that needs this
st just overriding and ignoring
the Linitan warning about not having "make -f" in the shebang line?
I would say no: debian/rules is still a normal Makefille and it still
calls "make -f" when executed (just indirectly via the make-special-vdr
wrapper script).
Tobias
--
To UNSUBSCRI
hat's just harder to integrate
> into our pbuilder build process.
>
> Tobias
Or verry little (although I probably get crucified for this):
mv debian/rules debian/rules-no-make
cat >debian/rules << EOF
#! /usr/bin/make -f
%:
$(MAKE) debian/rules-no-make $@
EOF
B
> Michael Tautschnig wrote:
>
> > Adhering to a standard actually decreases complexity. What may seem
> > "elegant" at
> > first makes it a lot harder for other people to step in. For example, the
> > VDR-solution IMHO doesn't decrease complexity, it merely hides it.
>
> Yes, it indeed hides som
Michael Tautschnig wrote:
> Adhering to a standard actually decreases complexity. What may seem "elegant"
> at
> first makes it a lot harder for other people to step in. For example, the
> VDR-solution IMHO doesn't decrease complexity, it merely hides it.
Yes, it indeed hides some complexity. Bu
The debian/rules file in the vdr* packages _is_ a makefile. It just
doesn't have the shebang line required by policy.
I don't think there's anything that prevents you from including it.
Also, if SPECIAL_VDR_SUFFIX is not set,
/usr/share/vdr-dev/make-special-vdr.sh just calls make
Am Mittwoch, den 28.10.2009, 19:05 -0500 schrieb Manoj Srivastava:
> > The solution we have right now is in some way "elegant", because you have
> > only to deal with a standard debian/rules and besides the different
> > shebang line there's nothing else to care about.
>
> Actually, there
> Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit :
> >
> > Debian Policy 4.9 says about debian/rules:
> >
> > "It must start with the line #!/usr/bin/make -f, so that it can be
> > invoked by saying its name rather than invoking make explicit
m cdbs rule might be possible. But it's not that
> > easy and it would make the debian/rules less readable.
>
> I beg to differ. It is really trivial, and it does not make the
> rules file less readable
>
> #!/usr/bin/make -f
> ifeq (,$(srip $(ENV_VAR_WE_LOOK_FO
iffer. It is really trivial, and it does not make the
rules file less readable
#!/usr/bin/make -f
ifeq (,$(srip $(ENV_VAR_WE_LOOK_FOR)))
include regular.mk
else
include special.mk
endif
Done.
> The solution we have right now is in some way "elegant", because you have
&
On Wed, Oct 28 2009, Tobi wrote:
> Fabian Greffrath wrote:
>
>> Why not so it the other way round, i.e. start two different scripts (or
>> the same script with different parameters) from a debian/rules Makefile
>> depending on the environment variable?
>
> Might be possible, but it would require m
Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit :
>
> Debian Policy 4.9 says about debian/rules:
>
> "It must start with the line #!/usr/bin/make -f, so that it can be
> invoked by saying its name rather than invoking make explicitly."
Dear all,
I also do not un
standard debian/rules and besides the different
shebang line there's nothing else to care about.
But putting the technical aspect completeley aside - with our "hack", the
debian/rules still bahaves as it should be. You can run "debian/rules" and
you can run "make -f de
Fabian Greffrath wrote:
> Why not so it the other way round, i.e. start two different scripts (or
> the same script with different parameters) from a debian/rules Makefile
> depending on the environment variable?
Might be possible, but it would require major changes to debian/rules, but
our goal
> > Personally I would vote for dropping the make requirement from the
> > policy all together. I might be mistaken, but I think none of the
> > build tools calls make explicitly with debian/rules. A debian/rules
> > might even be a Python or Rake script.
[Bernd Zeimetz]
> Oh god, no. And I'm not
Tobi wrote:
> Or should we just add a Linitan override? Or do we really need to use
> "#!/usr/bin/make -f" as the shebang line in debian/rules?
Use make. it is able to do all the things you're doing right now, including to
do different stuff based on an environment setting.
Because make-special-vdr.sh needs to modify debian/rules itself.
This way debian/rules doesn't get "contaminated" with stuff that
goes beyond the scope of building the regular Debian package -e
except for the shebang line.
Why not so it the other way round, i.e. start two different scripts
(or
On Wed, Oct 28 2009, Tobi wrote:
> Julien Cristau schrieb:
>
>> asks for a password.
>
> Sorry, wrong link:
>
> http://svn.debian.org/wsvn/pkg-vdr-dvb/vdr/vdr/trunk/debian/make-special-vdr.sh
>
>> also nothing in what you said explains why you
>> can't do what you want using a makefile.
>
> Becau
On Wed, Oct 28 2009, Tobi wrote:
> Hello!
>
> Debian Policy 4.9 says about debian/rules:
>
> "It must start with the line #!/usr/bin/make -f, so that it can be
> invoked by saying its name rather than invoking make explicitly."
>
> In the VDR and VDR plugin pa
Julien Cristau schrieb:
asks for a password.
Sorry, wrong link:
http://svn.debian.org/wsvn/pkg-vdr-dvb/vdr/vdr/trunk/debian/make-special-vdr.sh
> also nothing in what you said explains why you
can't do what you want using a makefile.
Because make-special-vdr.sh needs to modify debian/rul
On Wed, 2009-10-28 at 16:02 +0100, Tobi wrote:
> [1]:
> http://svn.opensourcefactory.com/svn/vdr/trunk/debian/make-special-vdr.sh
>
>
asks for a password. also nothing in what you said explains why you
can't do what you want using a makefile.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debia
Hello!
Debian Policy 4.9 says about debian/rules:
"It must start with the line #!/usr/bin/make -f, so that it can be
invoked by saying its name rather than invoking make explicitly."
In the VDR and VDR plugin packages, we use something like this:
/bin/sh debian/make-special-vd
On Tue, Apr 7, 2009 at 11:06 PM, Manoj Srivastava wrote:
> What am I missing?
One case I can think of; it is (possibly) common for sponsors to check
that the result from get-orig-source matches the contents of the
tarball uploaded to mentors by the sponsee.
--
bye,
pabs
http://wiki.debi
Argh. I forget to set Mail-Followup-To properly on the last message.
Please don't reply to every single package's address.
Regards,
-Roberto
On Mon, Oct 16, 2006 at 01:18:02AM -0400, Roberto C. Sanchez wrote:
> Greetings all,
>
--
Roberto C. Sanchez
http://people.connexer.com/~roberto
http:/
On Mon, Sep 18, 2006 at 10:36:11AM -0400, Nathanael Nerode wrote:
> > Christian Perrier wrote:
> >> In short, a note should only be used for IMPORTANT stuff, so actually
> >> all debconf notes should be priority highor should not exist!
> > It's better to simply remove them all: If it's an er
Quoting Frans Pop ([EMAIL PROTECTED]):
> On Monday 18 September 2006 16:36, Nathanael Nerode wrote:
> > Frankly, the kernel's "You NEED to restart your computer SOON" message
> > is a good example, if it's telling the truth. But that cheats by not
> > using debconf.
>
> Oh yes it does!
> When hav
> This note appears to warn the user that he has to restart applications,
> and only when the script is *sure* that there are applications to
> restart. I think it is harmless, but given that it will never appear to
> someone doing the default install, it is also useless now. Maybe it's
> worth rem
On Thu, 2006-09-14 at 19:41:53 +0200, Christian Perrier wrote:
> As a conclusion and combining both, I would really like to unsderstand
> why so many fellow developers insist on using LOW priority NOTES in
> their debconf templates and use them in maintainer scripts.
> Packages with low priority d
Christian Perrier wrote:
> I indeed had a brief talk with Javier FS at the Extremadura meeting
> and he had an argument *for* the debconf note: it is optionnally
> mailed to the local sysadmin
Mailing of debconf notes was disabled a while ago.
> and being a debconf note, it can be localized.
Tru
Quoting Joey Hess ([EMAIL PROTECTED]):
> Christian Perrier wrote:
> > In short, a note should only be used for IMPORTANT stuff, so actually
> > all debconf notes should be priority highor should not exist!
>
> It's better to simply remove them all: If it's an error, use the new
> error data ty
Christian Perrier wrote:
> In short, a note should only be used for IMPORTANT stuff, so actually
> all debconf notes should be priority highor should not exist!
It's better to simply remove them all: If it's an error, use the new
error data type, which will always be displayed no matter the pr
On Sep 14, Christian Perrier <[EMAIL PROTECTED]> wrote:
> Before launching a mass bug-filing campaign, I would like to get
> fellow developers opinions. Would there be important objections to
> such a campaign targeting first all packages using notes at low
> priority, then those using notes at me
mailcrypt -- config:36 mailcrypt/alreadydefault
Debian QA Group <[EMAIL PROTECTED]>
f-prot-installer -- postinst:28 f-prot-installer/failed
Debian logcheck Team
logcheck-database -- config:17 logcheck-database/standard-rename-note
Debian tpctl maintainers <[EMAIL PROTECTED]>
tpctl
Title: ctzgu DI
things do happen. world OFFBEAT Open your
ïðèâåò in 1929 AtQ and make them better?XOpJ nlTNKLw the blackout Lovely day
Religion divides in 1831 First or standart class? in 1953 It's nice
1 - 100 of 138 matches
Mail list logo
