On 2024-03-24 Samuel Henrique wrote:
> Hello everyone,
> Given our current time_t transition happening, which means packages
> are blocked from migrating to testing for weeks, and that unstable
> updates have become harder to apply, two critical CVE fixes for
> Firefox became impossible to get it
> On 24-03-2024 11:45 p.m., Samuel Henrique wrote:
> > In a recent case, the issue was addressed by performing a
> > testing-proposed-update of the package. This would allow firefox-esr to be
> > fixed on testing before the transition is over, but it would not work for
> > those
> > installing the
Hi Samuel,
On 24-03-2024 11:45 p.m., Samuel Henrique wrote:
In a recent case, the issue was addressed by performing a
testing-proposed-update of the package. This would allow firefox-esr to be
fixed on testing before the transition is over, but it would not work for those
installing the firefox
I moved to Mozilla's official packages for the time being since I didn't
want to downgrade to ESR for now.
Will resume with Debian's packages when the dust settles down.
On 25.03.2024 ÖÖ 8:26, Leandro Cunha wrote:
Hi,
On Mon, Mar 25, 2024 at 2:18 AM Paul Wise wrote:
On Sun, 2024-03-24 at 2
Hi,
On Mon, Mar 25, 2024 at 2:18 AM Paul Wise wrote:
>
> On Sun, 2024-03-24 at 22:45 +, Samuel Henrique wrote:
>
> > I'm sending this to d-devel because there should be a lot of testing and
> > unstable users on this list. If you're not running firefox 124.0.1 or
> > firefox-esr 115.9.1esr-1,
On Sun, 2024-03-24 at 22:45 +, Samuel Henrique wrote:
> I'm sending this to d-devel because there should be a lot of testing and
> unstable users on this list. If you're not running firefox 124.0.1 or
> firefox-esr 115.9.1esr-1, you should find a way of upgrading to those
> versions.
firefox
Hello everyone,
Given our current time_t transition happening, which means packages are blocked
from migrating to testing for weeks, and that unstable updates have become
harder to apply, two critical CVE fixes for Firefox became impossible to get it
through the official repositories:
https://secu
On Fri, 14 Oct 2016 21:47, d...@fifthhorseman.net said:
>> In a new temp directory do:
>>
>> GNUPGHOME=$(pwd) gpg-agent --daemon gpg .
>>
>> Or whatever you want to run under gpg-agent's control. This has been
>> there for ages.
>
> fwiw, this doesn't work (and actually returns an error) if
On Tue 2016-10-18 07:44:43 -0400, Ian Jackson wrote:
> Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669:
> Beware of leftover gpg-agent processes"):
>> On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
>> > 1. gnupg1-compatible authorisa
Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#840669: Bug#840669:
Beware of leftover gpg-agent processes"):
> On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
> > 1. gnupg1-compatible authorisation lifetime:
>
> I believe this is a deliberate change in se
On Sat 2016-10-15 11:21:29 -0400, Ian Jackson wrote:
> 1. gnupg1-compatible authorisation lifetime:
I believe this is a deliberate change in semantics from the upstream
GnuPG project. In particular, authorization for the use of secret key
material is now the responsibility of the gpg-agent. This
Lots of this discussion has been focusing on the test suite process
leak problem. But there are actually three separate use cases which
need something along the lines of my proposal; two of which are
regressions from gnupg1.
1. gnupg1-compatible authorisation lifetime:
Command line use of gpg b
On Fri, Oct 14, 2016 at 03:21:43PM -0400, Daniel Kahn Gillmor wrote:
> On Fri 2016-10-14 13:17:06 -0400, Ian Jackson wrote:
> > This (and the change to gnupg2) has now broken dgit's DEP-8 test
> > suite, when run under schroot. I'm discussing this in #840669 (CC'd).
>
> in particular, the lack of
On Fri, 14 Oct 2016 19:17, ijack...@chiark.greenend.org.uk said:
> authorisations, if the user types in a passphrase) have a lifetime
> limited by that of the gpg process which started the agent.
In a new temp directory do:
GNUPGHOME=$(pwd) gpg-agent --daemon gpg .
Or whatever you want to
On Fri 2016-10-14 15:18:40 -0400, Werner Koch wrote:
> On Fri, 14 Oct 2016 19:17, ijack...@chiark.greenend.org.uk said:
>
>> authorisations, if the user types in a passphrase) have a lifetime
>> limited by that of the gpg process which started the agent.
>
> In a new temp directory do:
>
> GNUPGHO
On Fri 2016-10-14 13:17:06 -0400, Ian Jackson wrote:
> This (and the change to gnupg2) has now broken dgit's DEP-8 test
> suite, when run under schroot. I'm discussing this in #840669 (CC'd).
in particular, the lack of a cleanup process breaks the test suite. If
the test suite had a cleanup proc
Ian Jackson writes ("Beware of leftover gpg-agent processes (was: Re: Changes
for GnuPG in debian)"):
> Johannes Schauer writes ("Beware of leftover gpg-agent processes (was: Re:
> Changes for GnuPG in debian)"):
>
> > Quoting Daniel Kahn Gillmor (2016-08
On Sat, Aug 06, 2016 at 12:56:58PM -0400, Daniel Kahn Gillmor wrote:
> ouch! please do file this as a distinct bug report, it's something i
> haven't run into myself and i'd like to track it down.
Done, that's #833596.
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . .
On Sat 2016-08-06 06:32:39 -0400, Stefano Zacchiroli wrote:
>> >> systemctl --user enable gpg-agent
>> >> systemctl --user enable dirmngr
>
> OTOH, doing this inhibited a proper start of my GNOME session at next
> login: only Nautilus started (I can tell because I've it handle my
> desktop icon
On Sat 2016-08-06 02:24:24 -0400, Paul Wise wrote:
> On Sat, Aug 6, 2016 at 12:41 AM, Daniel Kahn Gillmor wrote:
>
>> There are good reasons to want to have the agent running over time and
>> not terminating with the individual invocations of gpg1. In particular,
>> passphrase caching and smartcar
On Sat, 6 Aug 2016 08:24, p...@debian.org said:
> BTW, does this make parcimonie obsolete? I noticed that dirmngr
We plan to add similar fucntionality to dirmngr but that has not yet
been done and I am not sure whether we will have it for 2.2.
Shalom-Salam,
Werner
--
Die Gedanken sind fr
[ quoted text reordered ]
On Fri, Aug 05, 2016 at 02:43:30PM -0400, Daniel Kahn Gillmor wrote:
> The simplest way to see the control group hierarchy is with "systemctl
> status". When these processes are launched by the user service, they'll
> end up in the user@.service like this:
[...]
> If
On Sat, Aug 6, 2016 at 12:41 AM, Daniel Kahn Gillmor wrote:
> There are good reasons to want to have the agent running over time and
> not terminating with the individual invocations of gpg1. In particular,
> passphrase caching and smartcard management are useful features.
I noticed after upgrad
On Fri, Aug 05, 2016 at 04:02:07PM -0400, Daniel Kahn Gillmor wrote:
> My long-term goal is to have these things Just Work without *any*
> explicit user intervention.
>
> That is, i want: "If the package is installed, it should work for you."
> and not: "oh, if you want things to actually work, ju
On Fri 2016-08-05 15:03:29 -0400, Peter Colberg wrote:
> On Fri, Aug 05, 2016 at 01:51:07PM -0400, Daniel Kahn Gillmor wrote:
>> I don't think there's any need to add no-autostart in this case. in
>> particular, the daemon will already be running, so any consideration of
>> autostart will just det
On Fri, Aug 05, 2016 at 01:51:07PM -0400, Daniel Kahn Gillmor wrote:
> I don't think there's any need to add no-autostart in this case. in
> particular, the daemon will already be running, so any consideration of
> autostart will just detect and make use of the already-running daemon.
This is pre
On Fri 2016-08-05 14:17:23 -0400, Stefano Zacchiroli wrote:
> On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
>> On desktop systems (where i'd expect the majority of secret key access
>> happens), for folks who are running systemd, i recommend enabling the
>> systemd user servi
On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> On desktop systems (where i'd expect the majority of secret key access
> happens), for folks who are running systemd, i recommend enabling the
> systemd user services, as documented in
> /usr/share/doc/{gnupg-agent,dirmngr}/READ
On Fri 2016-08-05 13:39:10 -0400, Peter Colberg wrote:
> On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
>> On desktop systems (where i'd expect the majority of secret key access
>> happens), for folks who are running systemd, i recommend enabling the
>> systemd user services,
On Fri, Aug 05, 2016 at 12:41:18PM -0400, Daniel Kahn Gillmor wrote:
> On desktop systems (where i'd expect the majority of secret key access
> happens), for folks who are running systemd, i recommend enabling the
> systemd user services, as documented in
> /usr/share/doc/{gnupg-agent,dirmngr}/READ
Ian Jackson writes:
> Johannes Schauer writes ("Beware of leftover gpg-agent processes (was: Re:
> Changes for GnuPG in debian)"):
>
>> Quoting Daniel Kahn Gillmor (2016-08-04 18:29:03)
>> > One of the main differences is that all access to your secret key
>
On 08/05/2016 06:08 PM, Ian Jackson wrote:
> Could we not have gpg2 not only automatically launch the agent, but
> also automatically terminate it. This would provide the same UI and
> same persistence properties as gpg1.
Full ACK here, with the slight modification that the agent should
only comm
Johannes Schauer writes ("Beware of leftover gpg-agent processes (was: Re:
Changes for GnuPG in debian)"):
> Quoting Daniel Kahn Gillmor (2016-08-04 18:29:03)
> > One of the main differences is that all access to your secret key
> > will be handled through g
Hi,
Quoting Daniel Kahn Gillmor (2016-08-04 18:29:03)
> One of the main differences is that all access to your secret key will be
> handled through gpg-agent, which should be automatically launched as needed.
it might be important to note that gpg launching this gpg-agent process is not
optional
Hi,
Wendy Lin:
> Given ORACLEs very aggressive stance and intentional destruction of
> opensource communities like opensolaris.org it must be *CLEARLY* ruled
> out that there is *ANY* risk for Debian.
Wrong. You cannot rule out ANY risk, and the current legal landscape is
not compatible with CLEA
On 28 March 2014 12:51, Philip Hands wrote:
> Sebastian Feld writes:
>
>> Now that Redhat and Suse have been contacted by ORACLE regarding to
>> licensing the SMF patents a question arises for Debian:
>
> Have you read this:
>
> https://www.debian.org/legal/patent
>
> in particular, point 3.
>
On Fri, 28 Aug 2009, Raphael Hertzog wrote:
> On Fri, 28 Aug 2009, Santiago Vila wrote:
> > This is to warn interested parties that now that install-info is
> > GNU install-info, the probability of a package shipping a file named
> > /usr/share/info/dir.gz by mistake is now much higher than before
Hi,
On Fri, 28 Aug 2009, Santiago Vila wrote:
> This is to warn interested parties that now that install-info is
> GNU install-info, the probability of a package shipping a file named
> /usr/share/info/dir.gz by mistake is now much higher than before.
Note that lintian catches that:
http://lintia
Hello.
This is to warn interested parties that now that install-info is
GNU install-info, the probability of a package shipping a file named
/usr/share/info/dir.gz by mistake is now much higher than before.
Some packages using automake have a Makefile.in like this:
install-info-am:
[...]
Frank Küster <[EMAIL PROTECTED]> wrote:
> Dear fellow developers,
>
> the Debian TeX Task force is currently preparing an upload of TeX Live
> 2007 to unstable. With this version, teTeX will vanish as a separate
> package and only continue to exist as transitional packages.
I must apologize for
Now, it's finally possible for you to enlarge your penis
http://www.renonu.com/ss/
Don't live in a town where there are no doctors.
Don't be humble, you're not that great.
I don't mind a little praise - as long as it's fulsome.
Everybody likes a kidder, but nobody lends him money.
Are you happy about your size and sexual performance?
http://www.jnaz.net/ss/
I like to play saxophone because you don't inhale.
Moderation is a fatal thing. Nothing succeeds like excess.
When in doubt, use brute force
Why then the worlds mine oyster, Which I with sword shall o
On Tue, Sep 05, 2000 at 02:00:42AM -0500, Joseph Carter wrote:
> On Mon, Sep 04, 2000 at 11:54:05PM -0700, Joey Hess wrote:
> > > Software has bugs, it's a fact of life. New software is more likely to
> > > have unknown bugs that affect more people. What makes the Helix packages
> > > so nice is
On Tue, Sep 05, 2000 at 12:29:32AM +1100, Donovan Baarda wrote:
> I believe the infamous "aalib" affair actualy came out of a wishlist
> bugreport submitted to them by a user; the then frozen potato aalib was too
> low a version to meet all the helix dependencies. This meant people like me
> had to
On Mon, Sep 04, 2000 at 11:54:05PM -0700, Joey Hess wrote:
> > Software has bugs, it's a fact of life. New software is more likely to
> > have unknown bugs that affect more people. What makes the Helix packages
> > so nice is the turnaround time for fixes. I don't know how they do it,
> > but th
Joseph Carter wrote:
> Software has bugs, it's a fact of life. New software is more likely to
> have unknown bugs that affect more people. What makes the Helix packages
> so nice is the turnaround time for fixes. I don't know how they do it,
> but they do.
Maybe they have a dinstall delay of le
On Mon, Sep 04, 2000 at 04:06:49PM -0500, David Starner wrote:
> > packages into unstable. Helix is too stable for unstable, and too unstable
> > for stable.
>
> Not exactly true, as Helix Gnome is usually more cutting-edge than
> unstable Gnome.
In my experience, it's had a bug report to fix tur
On Tue, Sep 05, 2000 at 12:29:32AM +1100, Donovan Baarda wrote:
> packages into unstable. Helix is too stable for unstable, and too unstable
> for stable.
Not exactly true, as Helix Gnome is usually more cutting-edge than unstable
Gnome.
--
David Starner - [EMAIL PROTECTED]
http/ftp: dvdeug.dhi
G'day Joey,
I'm not subscribed to debian-devel, but wanted to add some comments on this
issue after reading the web archives. Because I'm not subscribed, I dunno if
my Cc to the list will work, in which case you can forward this to the list
as you see fit.
IMHO, the entire reason Helix exists as
On Wed, 30 Aug 2000, Peter Teichman wrote:
> I have one question. What is the preferred way for me to handle our
> gtk package? This is a library package that we actually apply some
> patches to for a slightly nicer user interface.
Well, we don't have much provision for flavors of shared librari
"JG" == John Goerzen <[EMAIL PROTECTED]> writes:
>> Don't forget to put this field in debian/control:
>>
>> Send-To: [EMAIL PROTECTED]
JG> Whoa! What packages understand this, and where is it documented?
Sorry this is a error.
The right place for this is in:
/usr/share/bug/$package/cont
Christian Marillat <[EMAIL PROTECTED]> writes:
> Don't forget to put this field in debian/control:
>
> Send-To: [EMAIL PROTECTED]
Whoa! What packages understand this, and where is it documented?
>
> Christian
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsub
On Wed, Aug 30, 2000 at 01:20:48AM -0600, Jason Gunthorpe wrote:
> 3) Libraries - All possible effort should be made to make Debian the
> primary source of libraries. Period full stop. This is so important
> because of what we are seeing with helix and their special library
> pack
Previously Christian Marillat wrote:
> Don't forget to put this field in debian/control:
> Send-To: [EMAIL PROTECTED]
Where did that come from That won't do anything at all and will make
dpkg-gencontrol complain loudly at you.
Wichert.
--
_
On Wed, Aug 30, 2000 at 03:50:08PM +0200, Christian Marillat wrote:
> "PT" == Peter Teichman <[EMAIL PROTECTED]> writes:
>
> [...]
>
> PT> This solution looks like the best one. I'll start rebuilding our
> PT> packages immediately.
>
> Don't forget to put this field in debian/control:
>
>
"PT" == Peter Teichman <[EMAIL PROTECTED]> writes:
[...]
PT> This solution looks like the best one. I'll start rebuilding our
PT> packages immediately.
Don't forget to put this field in debian/control:
Send-To: [EMAIL PROTECTED]
Christian
On Wed, Aug 30, 2000 at 01:20:48AM -0600, Jason Gunthorpe wrote:
>
> On Wed, 30 Aug 2000, Branden Robinson wrote:
>
> > > That is one mechanism of creating a private namespace, isn't another
> > > Setting the origin to something other than Debian?
> >
> > Please see elsewhere in this thread for
On Tue, Aug 29, 2000 at 10:02:04PM -0500, Branden Robinson wrote:
> > No, there is no difference between our apps and the upstream in most
> > cases. We do brand gnome-core and gdm, but those are the only packages
> > I can think of offhand. Those are only graphics changes, substituting
> > some of
Le Sat, Aug 26, 2000 at 03:07:03PM -0500, Joseph Carter écrivait:
> Perhaps the existing Gnome maintainers interested could help by working on
> the packages in CVS? This takes some load off of Peter who is currently
> trying to do the whole Debianization process as well as upstream work
> himself
On Wed, 30 Aug 2000, Branden Robinson wrote:
> > That is one mechanism of creating a private namespace, isn't another
> > Setting the origin to something other than Debian?
>
> Please see elsewhere in this thread for my other remarks on this subject.
>
> An Origin field is a great idea.
We ha
On Wed, Aug 30, 2000 at 01:28:18AM -0500, Branden Robinson wrote:
> On Tue, Aug 29, 2000 at 10:12:56PM -0700, Ryan Murray wrote:
> > stable Debian releases only have security changes and critical bugfixes
> > going
> > into them once released. I feel that the security/bugfix is more important
> >
On Wed, Aug 30, 2000 at 04:48:19PM +1100, Anand Kumria wrote:
> That is one mechanism of creating a private namespace, isn't another
> Setting the origin to something other than Debian?
Please see elsewhere in this thread for my other remarks on this subject.
An Origin field is a great idea.
On
On Tue, Aug 29, 2000 at 10:12:56PM -0700, Ryan Murray wrote:
> stable Debian releases only have security changes and critical bugfixes going
> into them once released. I feel that the security/bugfix is more important
> than any of the "extras" offered in the Stormix packages, so your suggestion
>
On Tue, Aug 29, 2000 at 10:02:04PM -0500, Branden Robinson wrote:
> > No, there is no difference between our apps and the upstream in most
> > cases. We do brand gnome-core and gdm, but those are the only packages
> > I can think of offhand. Those are only graphics changes, substituting
> > some of
On Tue, Aug 29, 2000 at 10:08:43PM -0500, Branden Robinson wrote:
> Don't do this. If you're hellbent on forking Debian packages just for the
> sake of doing so, or spraying them with Helix musk, then name the packages
> appropriately.
>
> helix-gnomecc
> helix-gnome-core
> helix-gdm
In the case
> In article <[EMAIL PROTECTED]> Raul Miller wrote:
> > I think this is so bad that every binary copy of grep 2.1-7 should be
> > deleted from every archive as soon as possible.
Herbert Xu <[EMAIL PROTECTED]> wrote:
> You mean 2.1-6?
Oops. yes.
I'd hand-patched my system and hadn't noticed that
In article <[EMAIL PROTECTED]> you wrote:
> I think this is so bad that every binary copy of grep 2.1-7 should be
> deleted from every archive as soon as possible.
You mean 2.1-6?
--
Debian GNU/Linux 1.3 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home P
Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> the broken grep (I think it is filed as a Bug already) will do a lot of
> damage to your system. It will kill your Windowmanger -list if you install a
> Windowmanager, and it will make the /etc/X11/config not work
> (user-xsession).
There are a bunch of
Hello,
the broken grep (I think it is filed as a Bug already) will do a lot of
damage to your system. It will kill your Windowmanger -list if you install a
Windowmanager, and it will make the /etc/X11/config not work
(user-xsession).
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. )
> The 0.93R6 sysvinit-2.57b used /var/log/initrunlevel as the file to
> communicate with init. The debian-1.0 version of sysvinit-2.57b
Interesting. I was just about to submit a report about how if I did a
shutdown -h now, it halted the system, and then if I hit ctl-alt-del I
got a message about
You (Chris Fearnley) wrote:
> 'Miquel van Smoorenburg wrote:'
> >I've changed the postinst script to create a symbolic link in /var/log,
> >so that it will (hopefully) work in all cases. It is also backwards
> >compatible with other programs (UPS watchdogs etc) this way.
>
> You might consider put
'Miquel van Smoorenburg wrote:'
>I've changed the postinst script to create a symbolic link in /var/log,
>so that it will (hopefully) work in all cases. It is also backwards
>compatible with other programs (UPS watchdogs etc) this way.
>
>If I don't get any replies saying "this is a bad idea" I'll
I hate to reply to my own messages, but..
You (Miquel van Smoorenburg) wrote:
> The 0.93R6 sysvinit-2.57b used /var/log/initrunlevel as the file to
> communicate with init. The debian-1.0 version of sysvinit-2.57b
> changed this to /etc/initrunlvl (as the default was in the original source).
I've
You (Helmut Geyer) wrote:
> Hi!
>
> There is a small problem with the new sysvinit (2.58-1) suite. Once you have
> installed it, you can't shutdown/reboot/halt the system as these use a
> different way of communicating than the 2.57* init (a FIFO, no longer a file).
> So please make copies of the
Something similar happened last time I upgraded init -- to Bruce's ELF
version.
Shouldn't packages doing stuff like that do some postinst _after_ rebooting
the machine? They could just add an rc file that removes itself once it
executes.
Thanks,
Jeff
Helmut Geyer <[EMAIL PROTECTED]> wrote:
>
Hi!
There is a small problem with the new sysvinit (2.58-1) suite. Once you have
installed it, you can't shutdown/reboot/halt the system as these use a
different way of communicating than the 2.57* init (a FIFO, no longer a file).
So please make copies of the old init,shutdown, halt and reboot pr
76 matches
Mail list logo
