Hi Frans Pop & debian-devel,
> Thanks! David Kalnischkies and I were able to reproduce a crash for
> sources that had no Packages file. This is fixed with the 0.7.23.1
For anybody further interested in the bug:
Something like a index-out-of-bounce, but libapt didn't access th
> I looked in /usr/share/doc/apt/examples/configure-index.gz first, but I
> could not find it there. Should it be added?
Yes, it should be. A few others seems to be missing also...
Will be added in the next upload round.
>> The description is far from being perfect and a few things are missing
>>
bug)
As we all know APT is a debian native tool and the base of a whole
bunch of other stuff so beside ranting about his shortcomings we
could also work on patches as the people with enough knowledge
to do this seems to be already around in this thread.
Thanks in advance and best regards,
Davi
e to join de...@lists.d.o for discussions/questions about APT. :)
http://lists.debian.org/deity/
Best regards,
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian
uestions are a better fit in d-mentors) and not what you think
is a bug in a package manager - if it is really a bug it should be expressed
with a proper bugreport against the package manager in question…
Best regards,
David Kalnischkies (Debian APT GSoC student)
--
To UNSUBSCRIBE, email to deb
2010/5/29 Ludovic Brenta :
> David Kalnischkies writes:
>> No. Replaces is used to say to dpkg: It is okay that this package
>> overrides files of the other package - otherwise dpkg would complain
>> loudly for good reasons. It doesn't say something about the
>> u
2010/5/30 Ludovic Brenta :
> David Kalnischkies writes:
>> 2010/5/29 Ludovic Brenta :
>>> David Kalnischkies writes:
>>>> No. Replaces is used to say to dpkg: It is okay that this package
>>>> overrides files of the other package - otherwise dpkg would
2010/5/31 Ludovic Brenta :
> David Kalnischkies wrote:
>> 2010/5/30 Ludovic Brenta :
>>> The consequence is that, despite the fact that these packages are
> broken
>>> (without the need for a Breaks: in their successor packages, BTW),
>>> aptitude prefers to
ks or Conflicts. Breaks is in general the nicer Conflict -
in some way they are the negative version of Depends and Pre-Depends:
Conflicts must be satisfied before the package is unpacked - so both
packages can't be in unpack (or higher) at the same time, while
Breaks only says that both can'
mplement it,
hints regarding a good error message are welcomed
as i can currently only thing about stuff like:
>>>>>
W: http://debian.example.org squeeze Release: The Validation date for
the archive has expired. (This can indicate an outdated mirror.)
<<<<<
(better late than never)
2010/6/1 Jacob Sparre Andersen :
> David Kalnischkies wrote:
>> 2010/5/31 Ludovic Brenta :
>>> Question 2: if I add Breaks: to a -dev package, which ones of Conflicts:
>>> and Replaces: should I also specify? (currently, both are specified; t
(better late than never)
2010/6/3 Ludovic Brenta :
> Jacob Sparre Andersen writes:
>> David Kalnischkies wrote:
>>> With the break you can force the update of old-libs, which
>>> could depend in their new version on the new-libs.
>
> OK, I just tried that (in
t;
> Could you shed some light or point me to some doc as to how this feature
> works? I'd like to know whether it can solve the problem or not.
E.g here http://wiki.debian.org/Renaming_a_Package
It is not documented very well currently as it can't be used for squeeze
and would
volunteer to work
on b) [0] - and the good thing is, you can even try and play with it already -
you just need an apt/experimental build (, a bit of luck) and the right
configuration options. See also README.MultiArch, but
(yes, correct, shameless self-advertisement).
Best regards,
David Kal
2010/6/26 Luca Bruno :
> David Kalnischkies scrisse:
>> The biggest showstoppers are as far as i know that
>> a) dpkg doesn't support it
>> b) APT doesn't support it
>> c) (not many) packages use it (last time i check ~24)
>>
>> c) is likel
(cross post to merge the two "independent" threads
http://lists.debian.org/debian-devel/2010/08/msg00338.html
http://lists.debian.org/deity/2010/08/msg00097.html
and to ensure everyone has the same information.
In case you want to discuss the topic feel free to do it at deity@)
We started this dis
will wait with an upgrade until this one or newer is in proper testing…
So, to let that actually work a user should not have a default-release…
Long story short:
If you want to get updates from an archive only if you pushed a version
previously from it: 100 => pin > 500.
Best regards
D
2010/8/26 Carsten Hey :
> * David Kalnischkies [2010-08-26 17:43 +0200]:
>> Long story short:
>> If you want to get updates from an archive only if you pushed a version
>> previously from it: 100 => pin > 500.
>
> Wouldn't adding a new field to Release files s
e treated like a second or third class member I can flip a few
burgers and harvest grapes and asparagus instead¹. I don't need to chose
debian for that if we would agree that we should handle students as consults…
The student need to be convinced to choose debian as organization and at
best (s)he
use one of the "bigger" tools to maintain your archive directly.
But, you say that it is "small", so i am tempted to say that pdiffs aren't
worthed the hassle. They can be useful if the Packages file is really big and
constantly updated, but if it is small… pdiffs have a
s - and after all
I can do a lot more in maintainer scripts than adding a sources.list entry,
so "mysteriously" added sources.list entries are not a disease
(or a misfeature of APT to allow it) but a symptom of the widespread
disease of trusting random packages from an unknown sources…
B
ckages
In that example you can also see why the sequence is important - swap
the stanzas in the preferences file and all archives which match o=Debian
will be pinned to 400 - which includes experimental!
But if that doesn't work i guess a bug report is better suited
than proceeding in hijack
-plugin at all. Any
> idea?
xfce4-mcs-manager recommends it.
As APT has no indication that this package can go away it does the
only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
the user will lose functionality…
(recommends are defined as installed on all, expect "unusual&q
On Fri, Nov 19, 2010 at 12:59, Yves-Alexis Perez wrote:
> On 19/11/2010 12:29, David Kalnischkies wrote:
>> xfce4-mcs-manager recommends it.
>> As APT has no indication that this package can go away it does the
>> only right thing (TM): Chooses to keep xfce4-mcs-plugins as
On Fri, Nov 19, 2010 at 22:10, Yves-Alexis Perez wrote:
> On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote:
>
>>
>> So, go and start reading. Debian has a lot of dependencies and you have a
>> lot of possibilities because of that.
>> You can't use
with our friends from ubuntu we should have a broad coverage and
voice for debian in the meeting and a lot to discuss but feel free to
provide (additional) topics and opinions for us to bring along to ensure
they will be all covered.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email
days, but to add
another quote: "It's xml, so we can add anything we like/need later".
I guess the DDTP project will be part of follow-up discussions as it is
similar to debtags and screenshots - its more or less the only working
solution - and you are right: all of them are badly n
On Thu, Jan 27, 2011 at 13:45, Andreas Tille wrote:
> On Thu, Jan 27, 2011 at 12:55:36PM +0100, David Kalnischkies wrote:
>> If I remember correctly, DDTP got a short mention and the result was:
>> "Wow, debian really has translations for package descriptions?!?"
>&
.
Workarounds were already presented, so i just want to add that you can
also disable locking completely with Debug::NoLocking in apt-get
(i guess aptitude accepts it also, but i haven't test it)
if you are feeling *extremely* lucky…
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, e
o generate "interesting" trees with it like #610991.
That said, as dpkg is essential it gets a preferred handling anyway in APT
(and friends) and will be unpacked/configured before non-essentials, so in
this specific case its more or less a no-op (in squeeze -> wheezy upgrade),
but tha
really impatient - as long as the mirror hasn't switch to the
usage of the newest ftpsync tool of course…
btw: The documentation on [0] doesn't include the InRelease file yet.
Any pointers where to "complain" about that? d-mirror, d-www, d-…?
Best regards
The hashsum mismatcher
On Mon, Jun 16, 2014 at 12:04:51PM +0200, Thorsten Glaser wrote:
> On Thu, 12 Jun 2014, David Kalnischkies wrote:
> > For your attack to be (always) successful, you need a full-sources
> > mirror on which you modify all tarballs, so that you can build a valid
> > Sources file.
new hash implementations - provided we would
have an implementation available of course.
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
"magic" would have made sense anyhow,
but I am not sure it is a good idea to change it now after 1½ releases
supporting it differently – and more importantly for me personally:
APT isn't going to support any of this before dpkg does.
Once bitten, twice shy…
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
ficult to
explain which ones these are without expecting a good understanding of
how files are acquired by apt, so I go with a "each time we can do it
for free" which is surprisingly often 'thanks' to our architecture).
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
t
every parser in the universe needs to be rewritten… (one of apts
testcases uses 'rev' as a "compression" algorithm. You just need to set
some options, advertise the availability in the Release file and you are
good to go…)
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
packages - it is simply needed and part of the job
description of a package manager. We have a "apt-get autoremove" for
removing packages apt things might not be needed anymore. aptitude does
run it by default.
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
On Wed, Jul 16, 2014 at 02:23:34PM +0200, David Kalnischkies wrote:
> With a slight change in semantic we could drop the field from the
> Packages file again anyhow: At the moment it is the MD5sum of the long
> description. If it isn't present the clients are expected to calc
an at least oldstable). You can populate a netrc-like file at
/etc/apt/auth.conf with them (create it if you must and set for it the
permissions to your liking!).
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
wisely as you will loose functionality"
all the way down to "this is a transitional package nobody will miss".
If you have a clever idea how to solve this, I am all ears…
Moo,
David Kalnischkies
signature.asc
Description: Digital signature
On Sun, Oct 19, 2014 at 09:32:54AM +0200, Matthias Urlichs wrote:
> David Kalnischkies:
> > > Apitude, too, *really* likes to choose 500 deletions rather than upgrading
> > > even a single package to a version with slightly-lower priority (as
> > > defined
> >
for that.
Not only because I am lazy, but because it would mean that everyone
would have done a pretty crappy job making Debian jessie the best release
ever if no init works reliably [totally unbiased on this one] )
Best regards
David Kalnischkies
signature.asc
Description: Digital signature
nt
in foo, foo-provider or your foo-conflicter… so, why you want to do that?
Best regards
David Kalnischkies
P.S.: These kind of questions seem better suited for debian-mentors@l.d.o.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Tro
On Mon, Apr 23, 2012 at 10:35, David Kalnischkies
wrote:
> On Mon, Apr 23, 2012 at 09:17, Harald Dunkel wrote:
>> How can I tell a Debian package to conflict with a real
>> package "foo", but not with other packages providing "foo"?
>
> That is easy:
pt's gpgv method (/usr/lib/apt/methods/gpgv) text interface instead of
reimplementing them, depending on what you actually need.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Troubl
I would personal tend toward ftp-master to be the authority with reference
implementation being dak, but they have no public mailinglist and dak isn't
used by all derivatives…
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
since 14. Apr 2009 (aka 0.7.21)
which means stable (squeeze) supports it.
Everyone who likes that should be thanking Jeff Licquia and Anthony Towns,
everyone who doesn't has to set Acquire::http::AllowRedirect to false.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to deb
On Mon, May 14, 2012 at 12:36 PM, Jonas Smedegaard wrote:
> On 12-05-14 at 09:51am, David Kalnischkies wrote:
>> On Sun, May 13, 2012 at 7:41 PM, Jonas Smedegaard wrote:
>> > Not yet switched but renewed the old name, advertising new site one
>> > only in words
lled.
Beside maybe wasting bandwidth in that case (for the sake of same version
for everyone in general) a pretty well defined behavior from my POV.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fbr_8a1thg+pre-4cnuweenom9el07m+w+jw__svgc...@mail.gmail.com
On Tue, May 15, 2012 at 2:56 AM, Russ Allbery wrote:
> Charles Plessy writes:
>> Le Tue, May 15, 2012 at 01:54:53AM +0200, David Kalnischkies a écrit :
>
>>> And the fields defining a difference in versions are:
>>> Installed-Size, Depends, Pre-Depends,
w that thought, the only repository which should give
any indication on how APT might work is the one created by the ftpmasters.
Actually that is not really true as APT could basically do anything,
but if it wants to keep the status 'debian native' package it better should.
And ftpmas
bly a lot of 404's.
Best combined with a strong recommendation on signing them.
Best regards
David Kalnischkies
P.S.: Could we please stop talking to three bugs and two mailinglists?
Especially as [0] suggests it is the wrong list…
[0] http://lists.debian.org/debian-devel/20
rea which isn't short on complexity already.
And that just for the "once in a blue moon" encounter of a crossgrade?)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
Transitional packages are your friend, conflicts are not" D.K.
I would be delighted by the quote, if I wouldn't be a bit embarrassed
that this comes from a mail I am not particular proud of …
Internet, "thou art a heartless bitch" (sometimes).
(or instead of blaming the we
;t download the
indexes for the pdiffs - but this is done also only a single time)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://list
allowed
Which dpkg version is that?
But as said, you can't use architecture specific dependencies in wheezy.
(The message is a bit confusing, :any doesn't make a lot of sense here
provided that it is the same without :any … or worse: any could mean
we are conflicting only with one
d stop talking in that style at all, but I
don't use n-m, so in that specific case, I don't care …)
Best regards
David Kalnischkies, who doesn't know whether to
laugh or cry about these kind of threads …
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a sub
se e.g.
apt-get download debian-archive-keyring/stable
(beside that this functionality is not in squeeze of course,
but aptitude has a similar command - but I haven't tried)
If you can convince me, the functionality might magically appear
one day in an APT version … ;)
Best regards
Davi
Also: build-dependencies, but that is probably not an issue for PHP.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fdjfr7jvnx6b0wgttjpunbhhsmzuw48chmn2kmf-de...@mail.gmail.com
isn't depending on apt-ftparchive
anymore ["just" "some" derivatives use it nowadays], so the binary is even
less important than you might think/remember.
Disclaimer: This is not a remark regarding AGPL.
I am just trying to correct misunderstandings in regards to APT.
riteria the solver might want.
(Still no checked what aptitude uses, but I bet its some sort of
'least disruptive changes' which is obviously better than priority
alone, but not at all working in your favor of course)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE
n I guess, but in case someone else reads the thread).
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fCtK_OcAwN8CcBG21CKCoJwcoouU36KhVSn_q=6_lu...@mail.gmail.com
end of the GSoC project. And there's also upstart as a quite
>> realistic option too.
>
>
> The difference is, however, systemd is already there […]
It is not "already there".
That was the whole freaking point of this "survey".
There is still enough time for
On Sun, Jul 14, 2013 at 2:38 PM, John Paul Adrian Glaubitz
wrote:
> On 07/14/2013 01:09 PM, David Kalnischkies wrote:
>>
>> At least I am seriously expecting that Debian isn't discarding the outcome
>> of a project it has officially endorsed to be under its umbrella fo
On Sun, Jul 14, 2013 at 3:47 PM, Florian Weimer wrote:
> * David Kalnischkies:
>
>> GSoC in Debian was announced a long time ago, enough time to raise
>> any objections against any proposed project.
>
> Not really, a GSoC project doesn't come with any guarantee, imp
On Mon, Jul 15, 2013 at 2:56 AM, Ben Hutchings wrote:
> On Sun, 2013-07-14 at 13:09 +0200, David Kalnischkies wrote:
>> On Sun, Jul 14, 2013 at 10:57 AM, John Paul Adrian Glaubitz
>> wrote:
>> > On 07/14/2013 06:45 AM, Thomas Goirand wrote:
>> >>
>> >
nalysis are obviously flawed as this popcon data can't
really be interpreted that way as its an apple to banana comparison and
way too few datapoints, but everyone likes misinterpret statistics as
"proven" by this thread – and statistics say that I am a pro-faker!
"I only believe in
" ~5 because libapt includes one, so it could be misused
by others (anyone remember the kernel depending on libapt-pkg-perl?).
Best regards
David Kalnischkies
P.S.: Could the table be enhanced with a description for the table headers?
I have no idea what an "ar slash" might be, and not r
ot; is the reason that it isn't
mentioned in the wiki.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fbswkxvu5ugcw8qjnerfxfqp8azcfxj5otecf1zsnf...@mail.gmail.com
and as a bonus, the filesize has
to match as well – not to mention that the file has to make sense…) and
at the time we do SHA1 is probably not an interesting candidate.
Best regards
David Kalnischkies
[0] expect in pdiffs as that is the only supported in there so far
--
To UNSUBSCRIBE, email
at some point in my history-digging, can't find it now though.
I think the most interesting point against such a relation might be:
Package: aptitude
Obsoletes: apt
(Not that we would be in a fight, but many people think we are, so lets
just add some fuel for them. KDE & Gnome wor
On Thu, Sep 5, 2013 at 11:34 PM, Philipp Kern wrote:
> On 2013-09-05 11:15, David Kalnischkies wrote:
> [ Provides/Replaces up thread ]
>
>> The policy defines two uses of Replaces:
>
> […]
>
>> So my simple question is, which combination of relations should that
&g
her people for your bugs next time.
I "recommend" reading debian-policy (§7.2).
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Fri, Sep 6, 2013 at 4:16 PM, Simon McVittie wrote:
> On 06/09/13 10:17, David Kalnischkies wrote:
>> For example, you made mplayer2 now an upgrade for mplayer.
>> I am not sure that is what their maintainers/upstreams intend.
>> (maybe it is, but I am not keen on letting f
) is no longer needed
…
Not that this would make the life of a maintainer necessarily easier,
but it at least frees the user (and the package manager) from deciding
if this remove requires user-attention or is just boring house-keeping.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, emai
is
architecture specific by design).
And could the virtual package maybe named 'opencl-loader-api-1' or
something?
Best regards
David Kalnischkies
P.S.: If you wanna play, try APTs testcases. :)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of &
systemd" isn't an init system.
'Normal' programs like GNOME do not depend on an init system as much as
they don't depend on a package manager. They depend on a certain userland,
like GNU, BSD, Plan9, busybox or … yes, or systemd. It just happens to be
that this userland contains
On Sat, Oct 26, 2013 at 4:31 AM, Nikolaus Rath wrote:
> David Kalnischkies writes:
>> On Fri, Oct 25, 2013 at 11:31 PM, Nikolaus Rath wrote:
>>> Thorsten Glaser writes:
>>>> Lars Wirzenius liw.fi> writes:
>>>>> I write a backup pro
ed up, even through his was
dropped by other lists, too…
All i can say about that: "Et tu, deity@l.d.o?"
debian-l10n-devel is properly right: Too many to-addresses…
Best regards
David Kalnischkies
[1]
http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2011-Novem
after an upgrade. So please
> %s/control/configuration/g. May be I shouldn't try to ask questions
> after midnight :-)
I think what you mean is best described/covered with the advice to
have a look at the manpage of 'dpkg-maintscript-helper', but i must
confess that the que
values and i am sure we will be happy to
incorporate it.
And please provide a valid email address in this report so we can
forward all messages complaining about these new default to you.
While looking forward to your bugreport,
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debia
ts own, but submitted
> as a patch to vim-scripts.
There is already a bug+patch for it in the bts:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624661
So you might want to contact the author, update/check the patch and
ping the maintainer(s) to get it included.
Best regards
Dav
if you can go into details what you remember exactly we might be able
to work on it - until then, my only comment to adding more packages:
"What should possible go wrong?" ;)
If APT survives i386 packages in amd64, it might survive some new ones, too.
Best regards
David Ka
lse in this multiarch-discussion was hinted that we could
sync on the version in (optional) Source tag instead to allow binNMU.
It's a bit too late (in my timezone) for me to do serious predictions on
difficult-levels on changing this in APT but i guess its relatively easy.
(the only problem i
On Thu, Feb 16, 2012 at 09:26, Goswin von Brederlow wrote:
> Russ Allbery writes:
>> David Kalnischkies writes:
>>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>>
>>>> Actually, why would that be the behavior? Why would dpkg --purge foo
>>&g
On Thu, Feb 16, 2012 at 23:10, Carsten Hey wrote:
> * David Kalnischkies [2012-02-16 03:59 +0100]:
>> On Thu, Feb 16, 2012 at 00:39, Russ Allbery wrote:
>> >>> it needs to find and remove foo:*
>
> foo:all (or foo:any) instead of foo:* would save the need to
On Fri, Feb 17, 2012 at 15:46, Jonathan Nieder wrote:
> David Kalnischkies wrote:
>
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library and not, say, a
>> plugin, a dev-package, a dbg-package or a fut
On Fri, Feb 17, 2012 at 19:53, Carsten Hey wrote:
> * David Kalnischkies [2012-02-17 14:15 +0100]:
>> You generously left out the paragraph describing how APT should
>> detect that the package foo is in fact a library ...
>
> My impression was that you think very library cent
pefully) some
debian contributors (yes, not necessarily developers) are upstream
for this package. In your case de...@lists.debian.org has the experts
(but i should warn you:
1. this is not a big army
2. you might end up talking to me again
3. not every front-end has a representative on that list
lation-* files as a description without caring for
Description-md5 ("side" problem still applies though).
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fAgOpwsdmmjZXm5P_UocZ0CjEsx=ohoe2gg_rybwnc...@mail.gmail.com
o have as default for backports, regardless of the drawbacks it has as the
alternative default is worse if not managed carefully.
(but as I said two years ago, not my decision either way)
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a s
On Fri, Jan 25, 2013 at 2:19 PM, Henrique de Moraes Holschuh
wrote:
> On Fri, 25 Jan 2013, Wookey wrote:
>> +++ martin f krafft [2013-01-25 16:06 +1300]:
>> > also sprach David Kalnischkies [2013.01.25.0020
>> > +1300]:
>> > > You can find much of the same
distributions nor at the scripts, so I have
no idea how (un)useful they will be and/or if they even work on apt << 0.6.
I am just saying that APT presence is not limited to Debian derivatives …
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAAZ6_fAvAc72z==4j=tokann6tvrgs9bmsgczj-hnq5y8xf...@mail.gmail.com
some
will be offended (not because of the gender or because she is missing a leg,
those dipshits are not bros, I mean the BBQ-bros)!
Thanks again bro and best regards
David Kalnischkies on behalf of the APT bros
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject
mpletion: Enhances are not handled)
It's just that a user shouldn't really be required to know what those are.
(if you digg deaper [usually in non-user facing texts] you will come across
"hard", "important", "soft", "negative" and "posi
entions like the immediate format EDSP).
On the pro-side, if that's finally done we can do a lot of funky stuff.
I wouldn't dare to hold my breath until then though, way too much stuff
creeps up on the bug side to even try to implement new bugs^Wfeatures.
(And no, pushing this as GSoC/
ach a consistent state,
from there you can easily install pending updates again.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caaz6_fa7p72ri3rbvkgjyz5xu726f1ndukw5iusjzjxdedb...@mail.gmail.com
the version in a
"canonical" form already at package creation time and warn in lintian
if a version wasn't written in the "canonical" form (as this usually indicates
a misunderstanding/bug already). Only problem I see with that is that dpkg
isn't providing an interf
I see a need for it, and I would like to reserve the syntax
we will use for build-profiles in build-dependencies also in "normal"
dependencies as use-profiles (as Johannes has already pointed to), but we
should really use the current information we already have much more and
take the new
re as well as people
as if it is important, so lets just mark it that way – or drop priorities
completely, but not some wishy-washy middle ground.
Best regards
David Kalnischkies
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
1 - 100 of 239 matches
Mail list logo
