Frans Pop wrote:
> The Debian CD team has made practical use of the extra time allowed for
> the release of Lenny by implementing some late improvements of the CD and
> DVD images available for Lenny
[snip]
Thanks for massive work!
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.deve
say which package man page belongs to.
Example for coreutils:
$ dpkg -S mv.1
coreutils: /usr/share/man/man1/mv.1.gz
git-core: /usr/share/man/man1/git-mv.1.gz
Look, first package is what you want.
Is this approach acceptable for your needs?
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(mail
Neil Williams wrote:
> A final alternative is the packages.debian.org website (has the
> advantage that it also allows looking up files within packages that are
> not currently installed).
We also have apt-file utility, which does the same without looking to the site.
--
Eugene V. Lyub
Diffs are like to be produced by dak, so
please try first
asking the ftp masters.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
Ukrainian C++ developer, Debian Maintainer, APT contributor
signature.asc
Description: OpenPGP digital signature
>=20
> Opinions?=20
I would prefer 1. or, slightly less, 4.
--=20
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
cumented in README.Debian in the insserv package.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.deb
--=20
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
#x27; and vice-versa.
Still can be resolvered by merging together (quite complex from packaging side
but possible).
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
edata' for first and 'puredata-extended' for second sound better for
me (I also think that 'pd' is just too common)
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
at a
> sponsor be automatically subscribed to the bugs for all packages he
> sponsors.
I think it's a good idea, but this probably belongs to another thread.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
is
> hidden on unpack (I certainly wouldn't if I were them), so implementing
> this is kind of pointless for Debian.
>
Seconded.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
signature.asc
Description: OpenPGP digital signature
tagged, removed, have version information set
> differently, or something in order to remove it from the UDD query for
> "squeeze bugs"?
IMHO this bug should be tagged 'sid' then.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer,
tlessly
> abrasive, inappropriate and offensive?
I also don't like the style of the answer. Nevertheless, while I see
your rationale, I doubt it's enough to overrule the maintainer.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Develo
prefer dropping only one hashsum (of 3) though.
> Would that already help quite a bit? The description and the hashsums
> probably contain a tad more entropy than the other bits and could
> already help quite a bit.
++
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.co
3:31:30 UTC on February 13, 2009, a celebration is expected as the
> Unix time number reaches 1234567890 seconds. [1]
Well, but Feb 14 is the Valentine's Day, fun seems to be already planned ;)
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maint
rom
> Opensuse?
APT team has a number of tasks to work. As usually, patches are usually welcome.
I obviously think that "incapable and obsolete" (from subject of the letter)
aren't the words which can characterize APT.
With 'APT contributor' hat on,
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature
grading packages may break your system (by design, in any software). So,
all downgrades should be done with caution and in not-automatic way.
> OK. Maybe i just supposed APT to do various things I'm used to expect from
> other package managements. Now i undrstand, reading the point of
to configure your mail client?
Or wait for a person who is conformable with this kind of mails.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature
Darren Salt wrote:
> I demand that Eugene V. Lyubimkin may or may not have written...
>
>> kc.ubuntu...@centrum.cz wrote:
>> <...>
> [note: reformatted]
>> I don't feel comfortable to answer on your mails. Use '>' for quoting,
>> don'
Package: wnpp
Severity: wishlist
Owner: "Eugene V. Lyubimkin"
* Package name: cupt
Version : 0.1.0
Upstream Author : Eugene V. Lyubimkin
* URL : http://wiki.github.com/jackyf/cupt
* License : GPL3+ | Artistic
Programming Lang: Perl
D
While this is true, the approach has two drawbacks:
1) depending on newer apt version would lead to uninstallability on
Lenny, while now cupt can be installed on pure-Lenny system
2) waiting for fix in apt can take significant time
Given all this, are there arguments against that chmod command?
--
Euge
Bill Allombert wrote:
> I use packages.debian.org each time I reassign a bug to a package to make
> sure the new maintainer is notified. I think this should be a best
> practice.
BTS automatically adds maintainers of package where bug went to To/CC of
reassign mail, doesn't it?
pt, one of the
> core Debian tools. Apt in turn relies on open standards like HTTP and
> FTP to interoperate with the rest of the world.
As someone who had to reverse-engineer APT repository format I fully
agree with the above. With one minor addition that some software which
is (non-core
yer for proposed functionality -- apt-get
(libapt) is not the only high-level package manager for Debian.
If I were you, I'd look into dpkg file triggers instead. Triggers will
by the way automatically solve the problem that you don't restart
a service 5 times if 5 libraries were u
On 2012-06-19 14:01, Ben Hutchings wrote:
> On Tue, 2012-06-19 at 15:29 +0300, Eugene V. Lyubimkin wrote:
> > Hello,
> >
> > On 2012-06-19 13:59, Tomas Pospisek wrote:
> > > This implies that an "apt-get install library" needs to trigger that
> > >
rio you describe.
>
> Recommends is wrong for metapackages because it gets upgrades very
> wrong. This is why it is used very marginally.
Standards should not depend on implementation details. I see zero
reasons why metapackages are (or should be) specific here. Whatever $it
that gets upgrad
ported by most if not all high-level packages managers in
Debian. Therefore it's totally appropriate for the task.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian
singlepackage', why $packagemanager now wants
to remove all $metapackage?"
, so I know I'm not alone. Using Recommends for non-core parts of
metapackages' dependencies would nicely solve that.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux
On 2012-07-10 20:15, Jonas Smedegaard wrote:
> On 12-07-10 at 07:35pm, Eugene V. Lyubimkin wrote:
> > 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 re
On 2012-07-10 22:21, Andrei POPESCU wrote:
> On Ma, 10 iul 12, 22:07:10, Eugene V. Lyubimkin wrote:
> >
> > ... And I disagree with that. No solution can override policy's "all
> > Depends must be satisfied". If one choose to support the "exclude from
>
On 2012-07-11 14:33, Gergely Nagy wrote:
> "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.
>
..]
I wrote a small program to list them, please find the (hopefully
awk'able and hopefully correct) output in attachment.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer
avahi-ui-utils: Recommends: 'vnc-viewer' [c
n, stopping developing the standards. Have seen examples of all
that occasionally.
I believe this hurts Debian (or any other project which chose to
not accept choices in certain areas) in the long run and don't fit to
'making [...] technically excellent' well.
YMMV.
--
Eugene V.
statements are not based on something I wrote myself. TIA.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
the cleaner testing.
P.P.S. Thanks for care.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
ey are. i18n/Index is referenced from Release.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@li
> certianly to ignore old "intent" and get on with it.
Absolutely disagree. Hijacking the ITP and/or package name without
saying a single word about that to the ITP bug thread is just plain
rude.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl
[ sorry for duplicate, Neil, pressed the wrong button ]
On 2012-03-26 09:17, Neil Williams wrote:
> On Mon, 26 Mar 2012 09:55:35 +0300
> "Eugene V. Lyubimkin" wrote:
[...]
> > No, it's not nothing, and it's not a pointless bureaucracy. Filing an
> >
- often porting bugfixes from already released upstream point releases
-- zero benefit to upstream/non-Debian users, less tested changes.
[4] if there is no viable alternatives
[5] as opposed to freely working on unstable
[6] but quite broad
--
Eugene V. Lyubimkin aka JackY
sucks, proposals welcome)
Doesn't require any middle steps.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe&qu
; and
'Recommends: y' -- 'Soft-Depends: y {90%}'.
Numbers/tags are quite arbitrary -- to give the picture.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-dev
Hi,
Thank you for comments.
2013-05-09 18:44, David Kalnischkies:
> On Wed, May 8, 2013 at 8:51 PM, Eugene V. Lyubimkin wrote:
> > Soft-Depends: a {90%}, b (>= 1.2) {20%}, c (>= 4) {99%}, c (>= 6) {70%}
>
> If we assume its already hard to decide "recommend
ax would be just as good.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
> dependent on score).
Unless this is documented in Debian Policy, please don't depend on this
specific behavior [1] and make a transitional dependency, AFAIK this is
how it was done for several transitions of Essential packages in the
past.
[1] there are other package managers, plus aut
how to proceed?
[1] mainly python-related + libidl0, > 800 binary packages in total
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
gt; But those hooks would only wotk for apt/aptitude. Not for [...] cupt
This is not true as well.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &qu
of operations)
No, I phrased it badly probably. Let me try again:
Dpkg::Pre-Invoke are called once. Then all dpkg invocations are called.
The Dpkg::Post-Invoke is called.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To
l (lib*, python-*,
> and so on). So, I still prefer a file-trigger.
Sure, using APT hooks is a hack (like Goswin said already). From the
time output above, I see it's now much faster than the man-db trigger? If
so, I would say go ahead with file triggers.
--
Eugene V. Lyubimkin aka JackYF, JI
;> greater than lenny and squeeze we should switch to Debian version
> >> numbers in the version instead of codenames post-squeeze.
> >> (OTOH it needs to be greater than +squeeze then, so +debXY won't do.)
> > Maybe +rXY as in r for release?
>
> r < s, though
count the situation for resuming broken upgrade, there is a
some chance you'll have to call dpkg manually or some hacks
to proceed anyway.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNSUBSCRIBE, email to de
a
> > strong objection.
> No. We *should* require consensus. The only way to force a change
> against the maintainer's will is tech-ctte or a GR. We do not have a
> clear decision in the APT team yet, though, as mvo is not here
> currently.
I wonder what's the point o
won't be
> able to restart apt to let it finish it.
As you and me pointed already, there are other (hard or easy) ways and
tools to fix the system. APT is not Essential, a system can live without
it.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, D
, depending only
> on some quite low-level libraries, so the impact should be minimal.
Yes, that's true.
For me, it's very-minimal-value positive versus minimal-value negative.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Devel
On 2011-05-20 13:58, Julian Andres Klode wrote:
> Eugene thinks it is unfair if APT were to pre-depend on things while
> Cupt would not [...]
No, I didn't say that. I did say it is possible to upgrade a Debian
system without APT, and you cannot attribute anything beyond this to
me.
-
rom completely different, non-Debian repositories:
Package: some-package
Depends: gnome
Recommended-When: gnome
And, still wearing the hat, negations are fairly easy to implement. If
we ever go for implementing conditional dependencies, negations are
great and powerful idea, I'd vote for them.
> http://lists.debian.org/debian-devel-announce/2011/05/msg7.html
> http://lists.debian.org/debian-devel-announce/2011/05/msg8.html
>
> Probably you should be subscribed to d-d-a and reading the list.
Both questions were posted before that d-d-a ones.
--
Eugene V. Lyubimki
pot further statements about this in the end of your mail.
So, no, this subthread is not about reverse recommendations, it's about
conditional recommendations. I don't need to rescan the whole repository
to satisfy '!A | B-plugin-A' given I scanned it once for Provides.
--
Euge
27;s a regular user access, not root one, given I
pre-checked package maintainer scripts before the installation.
'Recommended-When' gives them (= packages from any repositories) an
ability to be installed by default accompanying any package they want. A
major difference as for me.
--
Euge
'use' flag (i.e. by default), all 'optional' packages are
built. And like in the original proposal, there's a header in the
resulting .changes (and possibly in something else) which determines what
was the value of the 'use' flag when building, like
Built-With:
ll have to wait at least
2 stable releases until they could drop the relevant parts of the code.
Therefore I think _for this moment_ mandating in the policy will be too
strict.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
To UNS
On 2011-09-04 15:42, Vincent Danjean wrote:
> On 04/09/2011 14:44, Eugene V. Lyubimkin wrote:
> > While I also would want Debian to eventually get rid of circular
> > dependencies, I am not sure about (the value of) the benefits.
> >
> > For example, even by default d
Package: wnpp
Severity: wishlist
Owner: "Eugene V. Lyubimkin"
* Package name: cppformat
Version : 1.1.0
Upstream Author : Victor Zverovich
* URL : http://cppformat.github.io/
* License : BSD 2-clause
Programming Lang: C++
Description : fast
If as the project we agree that we
cannot uphold those standards anymore, we should either:
a) move such software out from 'main' (to 'contrib' or whatever else
applicable);
or
b) openly and officially relax our standards, stating that an ability to build
modified so
lated machinery.
What needs to be done:
- package a new upstream release;
- solve a (documentation-related) FTBFS;
- potentially make a shared library instead of a static library.
Regards,
--
Eugene V. Lyubimkin
C++ GNU/Linux userspace developer, Debian Developer
Hello Kristian,
On 23.10.2016 15:04, Kristian Erik Hermansen wrote:
> [...]
> Although APT theoretically protects tampering of packages in transit
> over HTTP based on the signing key, there are numerous ways to exploit
> the plaintext HTTP protocol in transit and the way APT handles some
> aspect
Hi,
[ please don't CC me directly ]
On 23.10.2016 17:20, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:23 AM, Eugene V. Lyubimkin
> wrote:
>> I'm a developer of a tool which downloads and validates Debian archives
>> in a similar way APT doe
Hi Russ, Kristian,
On 24.10.2016 07:19, Kristian Erik Hermansen wrote:
> On Sun, Oct 23, 2016 at 7:28 PM, Russ Allbery wrote:
>> The idea is to *add* HTTPS protection on top of the protections we already
>> have. You're correct that it doesn't give you authentication of the
>> packages without a
Hi Kristian,
To one of your side questions,
On 24.10.2016 02:33, Kristian Erik Hermansen wrote:
>> 1) Checking chain (e.g. gpgv and its callers) have bugs. True, same as
>> checking layer for secure transports also have bugs.
>
> Agreed. Please let me know of a good test case to validate that y
Package: general
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
When on iSCSI root, Debian freezes after sending the SysRq-c signal. SysRq-c
signal works in a frozen state just fine. I am aware
101 - 169 of 169 matches
Mail list logo
