Hi!
[...]
If you want to take this one step further, actually trying to crash an
application in a reproducible way, or trying to narrow down a bug to a
specific set of actions can be really helpful as well; for instance, if
there's a bug that says something like 'If I run this application, it
somet
If a bug is serious, and not a trivial thing, and if a patch has
been filed then a NMU could be applied.
But only a Debian developer can do so, right?
When saying "trivial" - did you mean easy to fix or the priority of a
bug (i.e., wishlist)?
[...]
Thanks,
Michael
--
To UNSUBSCRIBE, email to [EM
Usually, but I've sponsored NMU uploads by non-DDs before.
Sounds interesting - how does that work?
When saying "trivial" - did you mean easy to fix or the priority of a
bug (i.e., wishlist)?
I mean it should be a serious bug which is affecting real people
but has gone unadressed. Not something
also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2005.03.05.1840 +0100]:
ssh -i usualy helps.
not if you cannot influence how SSH is called.
Actually I don't really know, but maybe the environment-variable
DISTCC_SSH could be helpful.
Regards,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROT
Hi list!
I don't know which package I should file this bug against, but since the upgrade
of the openldap2-packages I'm seeing these errors quite frequently:
chown:
/home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/libraries/libldap/cyrus.c:468:
ldap_int_sasl_open: Assertion `lc->lconn_s
[...]
>
> Not to mention that you probably don't need SASL. Could not reproduce
> this yet and it seems that it normally occurs with ldaps or failover
> configurations.
>
In fact, I'm using ldaps and failover:
BASEdc=xxx
URI ldaps://x.y/ ldaps://z.y/
TLS_CACERT /etc/ssl/certs/cacert.p
Hi Torsten,
> Hi Michael,
>
> On Wed, Apr 20, 2005 at 12:09:15AM +0200, Michael Tautschnig wrote:
> > I don't know which package I should file this bug against, but since the
> > upgrade
> > of the openldap2-packages I'm seeing these errors quite frequen
[...]
>
> > - I've requested rescheduling the package on ARM as it should now build
> > successfully, but I haven't seen any reply on this one.
> >
>
> If you have written to [EMAIL PROTECTED], this is the right place. I
> wish you good luck, as it is roughly an alias to /dev/null.
>
[...]
Hm
> On Tue, Feb 05, 2008 at 08:17:04PM +0100, Hakan Ardo wrote:
> > Hi,
> > 15/12 I released gcc-avr version 1:4.2.2-1, but acording to:
> >
> >http://buildd.debian.org/build.php?pkg=gcc-avr
> >
> > the s390 buildd has not yet tried to build it. What might be the problem?
>
> http://buildd.deb
> Quoting François-Denis Gonthier ([EMAIL PROTECTED]):
> > Package: wnpp
> > Owner: François-Denis Gonthier <[EMAIL PROTECTED]>
> > Severity: wishlist
> >
> > * Package name: cyclone
> > Version : 1.0/CVS
> > Upstream Author : Dan Grossman, Trevor Jim, Greg Morrisett et al.
> > * U
> This is an improved version, thank you for the review.
>
> Package name: sourcenav-ng
> Version: NG3
> Upstream Author: Sourcenav Development Group <[EMAIL PROTECTED]>
> URL: http://sourcenav.berlios.de/
> License: GPL v2
> Description: Source code analysis, editor, browser and build tool
> so
> Paul Wise wrote:
> > On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> >
> >> OTOH, maybe you're just too incompetent for that.
> >
> > Insulting contributors really isn't helpful Josselin.
> >
>
> But the same it true the other way around. Imho it's also not ok
[...]
> Some people really like mentoring and training others and find that
> immediately rewarding. Those people are wonderful and deserve all the
> praise we can give them. For the rest of us, I think it's often a lot
> to expect of people. That sort of training is in many respects
>
[...]
>
> What might work quite well, however, is to have "bug janitors" (a la
> kernel janitors) who look at new bugs that have received no attention
> for, say, two weeks. If a bug gets reported against a package, and the
> package maintainer doesn't react to it, then the janitors can look at
>
[sorry for cross-posting, I guess this thread should move away from
debian-devel, but I'm not subscribed to any of the others]
> Hello,
>
> I would like to use a system to install automatically all my debian pc.
> But
> i don't know wich could be the best between FAI and PRESSEED.
>
> Somebody co
> On Sat, Jun 21, 2008 at 07:34:59PM +0200, Holger Levsen wrote:
> > Hi,
> >
> > On Saturday 21 June 2008 15:52, Alexander Wirt wrote:
> > > I'm still not that sure if its a good idea to add a non-offical debian
> > > repo
> > > keyring into the archive...
> >
> > Nobody is forced to install it
> Am Mittwoch, 25. Juni 2008 21:53:24 schrieb Agustin Martin:
> > Each spellchecker has currently some special features. Fortunately, the
> > only thing where ispell is stronger than the other spellcheckers (support
> > for pseudocharsets like 'a, "a, \'a, ... ) is already included in aspell
> > de
> Am Dienstag, 1. Juli 2008 12:33:18 schrieb Lars Wirzenius:
> > ti, 2008-07-01 kello 12:10 +0200, Thibaut Paumard kirjoitti:
> > > Come on, UTF-8 is good.
> >
> > UTF-8 also 16 years old. That's enough for people to get driver's
> > licenses in the US, to have legal sex in many parts of the world,
> Michael Tautschnig wrote:
> > Debian's Social Contract says that "Our priorities are our users and free
> > software". It does _not_ say that "Debian should tell users what is good".
> > Right?
> >
> Taken to the extreme, this would m
[...]
> So what is the right course of action here?
>
> 1) unset CDPATH in every single shell script there is?
> 2) never use relartive paths for cd in scripts?
> 3) shoot the user for doing something dumb?
> 4) disable CDPATH in /bin/sh (or is that POSIX?) or non-interactive
>scripts (would b
[...] (cool stuff)
> >
> > I'm now wondering whether something like this already exists (I
> > couldn't find anything, though). I'm also not sure where to put this.
>
> gnatbind could be instructed (-E) to store non-symbolic traceback in
> exception
> occurrences, which would be printed out as
> Package: general
> Severity: important
>
>
> On this system I installed a squeeze chroot using the following command:
>
> debootstrap squeeze /chroot/squeeze-x64-lighttpd-chroot
> http://ftp.debian.org/debian/
>
> This works as expected but when I stop the chroot, the system shuts as well.
>
> On Monday 26 October 2009 09:22:26 Marco d'Itri wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > Seconded.
>
> Thirded.
>
+1.
Thanks for bringing this up,
Michael
pgpDxjsmOMyTR.pgp
Description: PGP signature
> 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 understa
> 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,
[...]
>
> 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
> 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 completeness: Policy states that
> Hi,
>
> there are several tools that generate C source code that is later
> complied in object code, e.g. yacc, lex or valac. automake defaults to
> distribute these built intermediate files, so they are usually not
> regenerated during a build.
>
[...]
Why do you restrict this question to g
Hi!
I'm maintaining the gcc-h8300-hms package and had another upload of the package
through my sponsor (I'm not a DD yet). However, unlike 1:3.4.6-1, it FTBFS
(http://buildd.debian.org/fetch.cgi?pkg=gcc-h8300-hms;ver=1%3A3.4.6-2;arch=hppa;stamp=1169399342),
which is strange for 3 reasons:
- the di
Hi!
As far as I understood it, _at_buildd.debian.org is the right place for
getting some package removed from not-for-us, however, I'm seeing no reply from
the s390 admins as far as the gcc-h8300-hms package is concerned. Is there maybe
someone on this list who could help out?
Best,
Michael
pg
> Hello,
>
> Can I please have some input into this bug report?
>
> The report itself seems valid, ideally these packages shouldn't conflict.
>
> Solving this in such a way as not to break lots of stuff could be
> awkward though.
>
> Ideas?
>
Are you guys really sure that alternatives are so mis
> Yeah, I'm reasonably sure that alternatives are wrong for kadmin.
> Editor is intended to be used by a user. Kadmin is often used by
> users but is also quite often used by scripts.
>
[...]
Well, if alternatives is the wrong approach, let's try an analytical approach:
- heimdal-clients and kr
Hi all,
I just added a symbols control file to the latest upload of the diagnostics
library. I started out with a single libdiagnostics0.symbols file, which caused
an FTBFS on all archs [0]. So we all know that C++ name mangling has its
downsides, but in this case it becomes a real PITA. Though, i
> On Thu, Aug 21, 2008 at 12:37:38AM -0700, Steve Langasek wrote:
> > > Where did you discuss this mass filing of (useless) bugs before you
> > > submitted them?
>
> The previous discussions has lead nowhere. No use in discussing it yet
> again, instead it's time to act!
>
But mass-bug-filing wit
[...]
> > So, it is much better these to be detected and probably rejected
> > before doing any more harm on their way. Low quality packages won't help
> > users either, nor these users get the finally fixed and brought into
> > relatively sane shape package faster.
>
> I'm quite sure that most
> On Thu, Dec 18, 2008 at 01:22:40PM +0100, Sandro Tosi wrote:
>
> > So, how many are in favor of redo *completely* the vote (in more
> > ballot, the first being the one for lenny ONLY)? how many should we be
> > to let it happen? how many should be in contrary to stop this re-vote?
> > how can we
[...] (Sorry for only focusing on the below point, it was a really nice, but at
the same time also scary read!)
>
> One bright spot is that I think there are fewer poisonous people in
> positions of authority in Debian now than in many points in its
> history. We have a great leadership team, in
[...]
> - New features:
[...]
> support for realtime mount options
I think this^ was meant to be "relatime", and it is a single mount option.
[...]
Thanks for the great work,
Michael
pgpC6Pq9hQSOv.pgp
Description: PGP signature
[...]
>
> The policy definition of 'standard' is:
>
> These packages provide a reasonably small but not too limited
> character-mode system. This is what will be installed by default
> if the user doesn't select anything else. It doesn't include
> many la
[...]
>
> Actually, I misspoke in saying that mtr-tiny is the only traceroute we have
> by default. iputils-traceroute is also installed at Priority: important; but
> iputils-traceroute is far less useful on modern networks than mtr-tiny is.
>
> If traceroute belongs in important, then mtr belon
[...]
>
> > I could buy that for mtr-tiny, but which average user can do anything
> > meaningful with strace so that it needs to be in standard? If you need
> > it you have bug, and the average user will report that $upstream
> > (debian, developer, wherever). And can then install it if asked to
>
[...]
> Michael Tautschnig
>binutils-h8300-hms
>
[...]
Fixed in unstable.
Best,
Michael
pgpiPwdmopCV1.pgp
Description: PGP signature
[...]
> I use aptitude for my everyday work. On my desktop, I really appreciate
> pulling in Recommends. On cluster compute nodes, I don't. But I can turn
> it of easily without being "forced" to use apt-get just because I'm on a
> different type of machine. Compute nodes are what I'd call an "unus
> I finally got through the test builds of all the source packages in sid for
> i386 using dpkg-buildpackage -j3 on a dual core machine. The results as
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .
> Some statistics:
>
[...]
BTW, Daniel, it would be nice if you
> I finally got through the test builds of all the source packages in sid for
> i386 using dpkg-buildpackage -j3 on a dual core machine. The results as
> before are at http://people.debian.org/~schepler/build-logs/bymaint.html .
> Some statistics:
>
[...]
Wouldn't it have been wise to use len
[...]
> > I understand your need, but in this case (as opposed to the others you
> > mention) I believe a new field is not the right solution. The reason is
> > that in the general case too many information would need to be encoded
> > in such a field; that's why a machine interpretable copyright
> On Sun, Dec 02, 2007 at 11:13:53PM +, Ben Hutchings wrote:
> >It appears that ExtUtils::MakeMaker, a standard Perl module commonly
> >used to generate Makefiles for Perl modules, emits the rule:
> >
> >install :: all pure_install doc_install
> >
> >This appears to account for the failure of s
[...]
>
> I am requesting comment on this approach, review of my project, and
> looking for guidance. Though I have tried for 7 years, I have not
> been able to make the breakthrough into the community (most likely
> owing to a lack of social skills). I tried to discuss this project on
> the Deb
> Robert Collins <[EMAIL PROTECTED]> writes:
> > On Wed, 2008-01-02 at 00:29 +, Colin Watson wrote:
>
> >> Some packages actually do need to shut down cleanly; in the case of a
> >> database, for example, such a change could cause data loss.
>
> > Surely no more than a hard power failure(*),
> * Russ Allbery <[EMAIL PROTECTED]> [2008-01-12 09:11]:
>
> > Rafael Laboissiere <[EMAIL PROTECTED]> writes:
> > > The name of the S-Lang library is sometimes wrongly spelled as "slang". It
> > > would be good to have this fixed but if you add a rule slang -> S-Lang in
> > > Lintian you will hit
Hi all,
With the recent upload of diagnostics I've again been bitten by dpkg-gensymbols
[1]. As you might notice, the symbol is/was there, just the mangling scheme
seems to have changed. For one, the next upload will be the third upload just to
fix changed symbol names on alpha. One could argue th
First of all, I'd like to say a big THANKS to all the people maintaining Xen
within (in of course also outside) Debian; you really saved us lots of money and
energy (which is both, electrical and that personal one).
[...]
>
> > 4) What will be our preferred server virtualization option for non-
>
> I would like to request a rebuild of one of my package on armel. It built
> fine for last-5 to last-2 but both last-1 and last failed due to timeouts --
> I think ot simply tried to build on a smaller machine.
>
> As I can never remember what the porter / admin group emails are -- where do
>
[3.4 vs. 4.0 ...]
>
> Based on my experience with Xen I think that we should have both. Then if
> one
> doesn't work we can try the other.
>
> My impression of Xen stability is that trying two different versions and
> hoping that one will work is a good strategy for any given server.
>
> Ba
> On Tuesday 07 September 2010 12:02:38 Jean-Christophe Dubacq wrote:
> > What about using nc ?
> > nc -l < /etc/passwd
> >
> > http://localhost:/ => bingo.
> >
> > We will probably not convince you, but there are way too many
> > alternatives to make the packaging effort worth the time.
Hi all,
(Dared to fix CC/Subject which seemed to be somewhat broken in initial email.)
> The release team have been asked to remove ClamAV from testing (and
> hence the next stable release. See bug #587058.
>
> The issue seems to be that it's not supportable in stable due to the
> upstream maint
Sorry, debian-rele...@bugs.d.o really doesn't exist...
> Hi all,
>
> (Dared to fix CC/Subject which seemed to be somewhat broken in initial email.)
>
> > The release team have been asked to remove ClamAV from testing (and
> > hence the next stable release. See bug #587058.
> >
> > The issue see
[...]
>
> Here comes the bug: GNUmed will, given appropriate
> circumstances, OVERWRITE the first allergy against Sugar.
>
> Three years later, Debian 10 has been released and you
> return because of FatigueFromPackaging.
>
> I prescribe Sugar, which usually helps against
> FatigueF
Hi Alastair,
I'm by no means a bsd expert and you actually might want to redirect your
question to debian-...@l.d.o instead.
> I've a strange issue: I've a perfectly ordinary package, cmor, which fails to
> build on s390 and kfreebsd-amd64. In both cases it fails while trying to
> build a test
(CC'ed debian-devel as this was a not-so-well coordinated MBF without
announcement to debian-devel, dd-list, usertags; so maybe at least further
discussion can happen there)
Hi Florian,
[...]
>
> These lines from this package's maintainer scripts suggest that it likely
> is affected by the vulne
[...]
>c. his means there will be no need for /etc/kernel-img.conf file any
> more.
[...]
Isn't this file also read in the postinst of the "official" kernels? In FAI we
had several issues when kernel-img.conf was missing or hadn't had the proper
values in there.
Best,
Michael
pgpuCu
>
> [Daniel Baumann]
> > although probably almost everyone already does, it's finally time to
> > drop nfs-user-server (nfs-kernel-server has got support for nohide).
>
> When are host netgroups expanded by nfs-kernel-server? I had the
> impression that only the user space server would expand th
> Bastian Blank wrote:
> > On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote:
> > According to my knowledge of dak, the sections are global. Which means
> > that we don't have to worry about a possible kernel update for
> > lenny+1/2. Am I correct with that?
>
> The sections are define
> Holger Levsen wrote:
> > Hi Luk,
> >
> > On Freitag, 20. März 2009, Luk Claes wrote:
> >> Below a list of packages/maintainers that use ifconfig/route/netstat:
> >
> > How did you create that list? You seem to be missing a few..
>
> By looking at dependency relations with the net-tools package
[...]
>
> I'm unsure why we need *any* 32-bit libraries or binaries on an
> amd64 system. If one needs to run 32-bit software, it is possible to
> debootstrap an i386 system and use it as a chroot. Using a tool such
> as schroot handles all of the kernel personality and chroot details,
> and eve
> Hi,
>
> As some of you may be aware, myself and a few others are working towards
> an AVR32 port of Debian, which is now making good progress. One problem
> we've come across is since AVR32 is such a new architecture, a fair few
> packages have config.{sub,guess} files that are missing the archi
> Hi,
>
> On Montag, 27. April 2009, Philipp Kern wrote:
> > Interestingly you did it again, ignoring the list Code of Conduct.
>
> As it sadly happens many times every day. And as long as there are no means
> to
> enforce it (either pure social or aided by technology), it will continue to
> h
Hi Holger,
On Sat, Nov 08, 2014 at 15:12:42 +, Holger Levsen wrote:
> Hi,
>
> On Samstag, 8. November 2014, Holger Levsen wrote:
> > It would be trivial to turn this into a jenkins jobs, shall I?
> >
> > It seems to me, there could be several other UDD querying jobs as well, so
> > my first
> Hi,
>
> I would like to ask what would be general opinion to add functionality to
> BTS to be able to blacklist[*] certain people from filling the bugs
> directly.
>
[...]
> * - It doesn't have to be blacklist per se, it could be a queue which would
> be viewed by some fresher minds, who still
> Hello,
>
> With the recent setup of the parallel build infrastructure using clang
> instead of gcc [1], I would like to start to report
> bugs on packages failing to build with clang (with patches if possible).
> The severity would be minor.
> Of course, I would do that only when the issue is up
Hi Sylvestre,
[...]
> I started to report them (with patches for now) with minor as severity:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=clang-ftbfs;users=pkg-llvm-t...@lists.alioth.debian.org
>
You might want to take a look at
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=m...@deb
> Hi,
>
> > On Wed, Jun 05, 2013 at 09:37:54AM +0900, Charles Plessy wrote:
> > > Le Tue, Jun 04, 2013 at 02:06:26PM +0200, Niels Thykier a écrit :
> > > >
> > > > Our automated tools for finding RC buggy leaf packages in testing have
> > > > found 79 potential candidates (see attached files).
> >
[...]
> > clang.debian.net lists 39 instances of these, though I think the buildd
> > is a bit behind so there are probably a few more.
>
> At least one more of the 432 "Not categorized" is also due to this
> missing feature in clang (reprepro). As clang seems to gives quite
> misleading error mes
> On 14/06/2013 13:49, Wookey wrote:
> > +++ Matthias Klose [2013-06-14 13:35 +0200]:
> >> Much more often than I do like it, I see bug reports for the toolchain just
> >> pointing to a build log. Then looking at the build log, you often just see
> >>
> >> CC ...
> >> CCLD ... (sometimes even co
Hi Alexandre,
Many thanks for this effort, this sounds really interesting.
[...]
> You can download the list of affected packages, with their maintainers
> [3], generated with dd-list, as well as a sample bug report for
> gcov-4.6 [4]. The bug report contains:
> 1) the bug report that will be m
Hi Alexandre,
(Just replying regarding the point I had raised.)
[...]
> > Can one also access, even before you go and file bugs, information for other
> > packages? I cannot actually find any reports for the package listed in the
> > dd-list under my name in your Packages, Runs, nor Programs page
> BTW, the mails you have been sending with links to the crashes have
> been going to publicly archived lists, not sure if you meant for that
> to happen though?
>
I don't think the Mayhem team is at all to blame for that: we seemingly simply
don't have the necessary information in place.
For m
> On Mon, Jul 22, 2013 at 04:39:54PM +0100, Michael Tautschnig wrote:
> > [...]
> >
> > I feel the subject of this thread is not very well aligned with your
> > reasoning -
> > I don't think innovation==breaking things!? At least for myself the init
Hi Paul, hi all,
> Ahoy, fellow developers,
>
>
> Having followed the recent threads, I've been growing concerned - not of
> sticking with an old init system, or switching to a new one, or even the
> god-aweful tone of every damn post on that thread (srsly guise).
>
> I'm mostly concerned that
Hi Zack, hi all,
> On Sun, Aug 25, 2013 at 05:09:22PM +0200, Niels Thykier wrote:
> > How you can help (NEW-TEST-HELP)
> >
> >
> > Add tests to your packages. The full specification for these tests
> > are available from [AUTOPKG]. If you need inspiration, consi
Hi,
While rebuilding our archive using pbuilder I noticed that all packages
build-depending on gnome-pkg-tools failed to build. That led me to filing
#684503, which I'll quote here for convenience:
| The file control.header ends with an empty blank line. As the contents of that
| file is prepende
> Le lundi 01 octobre 2012 à 14:43 +0100, Ian Jackson a écrit :
> > This wouldn't help people doing backports or whatever. I think this
> > should be fixed in the packages involved.
>
> Changing gnome-pkg-tools to replace the blank line with an empty comment
> is trivial. In unstable.
>
> How d
> Le Mon, Oct 01, 2012 at 11:00:54PM +0200, Jakub Wilk a écrit :
> > * Michael Tautschnig , 2012-10-01, 14:25:
> > >>By policy, blank lines separate paragraphs, comments are
> > >>discarded, so we end up with an empty first paragraph. Policy,
> > >>
> On 2012-10-03 11:01, Michael Tautschnig wrote:
> > [...]
> >
> > But then either all build infrastructure (and also lintian) don't use
> > debian/control, or all these tools tolerate that blank line (with the
> > exception
> > of pbuilder).
> >
Hi,
> As we recently announced [1], we have been working on a complete
> re-implementation of dput [2]. As of today, the package is available in
> Debian Unstable [3] ready for early adoptors.
>
[...]
What are the chances of dput-ng becoming available in backports (well, once we
release, backpor
Hi,
[...]
> CPU:
>
> The whole script producing the output above took 7 hours to run on a 2.5GHz
> Core i5 for all suites and all architectures (38 combinations). This is
> because
> generating strong strong dependencies for all packages in the archive takes
> 8-10 minutes with current archive s
> Thorsten Glaser writes:
>
> > Jonas Smedegaard jones.dk> writes:
> >
> >> Quoting Michael Kaserer (2014-01-08 11:00:50)
> >> > We are two students currently working on a research project regarding
> >> > motivation for contributing to Open Source projects. You can help us
> >> > by filling o
Hi Jan,
>it's a too big a job to do by myself, and maybe the answer already exists:
>
>When I would download all Debian source packages, extract them, determine
> of each the programming language it is written in and the SLOC, what would be
> the percentages of each programming language u
On Sat, Apr 19, 2014 at 14:26:59 +0300, Riku Voipio wrote:
[...]
> Riding the Heartbleed publicity wave seems unwise, unless you can
> propose a hardening flag that would have protected users from
> Heartbleed. Else, Heartbleed merely serves on a example
> how wallpapering problems over with "harde
On Mon, Apr 28, 2014 at 16:45:56 +, Thorsten Glaser wrote:
> Shachar Shemesh debian.org> writes:
>
> > the changes there is a runtime check for undefined behavior. Just
> > compile with -fsanitize=undefined, and your program will crash with
> > log if it performs an operation that
Hi all,
[...]
> # package quality
> Advocate: Holger Levsen and Luk Claes
> State: confirmed
> Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
>
> This is a never ending goal of sustaining our packages quality by
> improving our tests and following up closely... so needless to sa
[...]
> • Read-only root
>
> Depends on /run. Having /run will allow remaining writable files
> under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
> Identifying and fixing/removing packages writing to /etc during
> their normal operation would be a worthy release goal.
>
Hi Harri,
> would it be possible to support combined dependencies,
> e.g. if package A and B are installed, then package C(A)
> has to be installed, too?
>
> That might be helpful for dkms packages, for example.
> A would be the kernel, B the dkms package, and C(A)
> would be the headers for A.
>
Hi all,
[...]
>
> No, you can't install B without C(A) if A is installed, that's the whole
> point of conditional dependencies. Thus at the second command apt would
> pull in C(A) or throw an error if it's uninstallable.
>
> If A is installed, B gains Depends:C(A).
> If B is installed, A effect
Hi again,
[...]
>
> B _does_ depend on C(A), if A is installed.
>
So B depends on
( A & C(A) ) | something-else
> > ... time passes ...
> >
> > magic install C(A) ???
> >
> >
> > Isn't all you want a hard dependency of dkms on both the Linux kernel and
> > its header package? It seems th
[...]
>
> The problem is that perl and perl-modules really are one package that was
> split apart solely to get the (large) architecture-independent parts into
> an arch: all package.
>
Wouldn't this problem be solved by moving the contents of perl to, e.g.,
perl-bin, making perl a dummy package
On Thu, Nov 27, 2014 at 10:50:26 +, Edmund Grimley Evans wrote:
> http://wiki.debian.org/ArchitectureSpecificsMemo
>
> Some suggestions for improving this table:
>
> 1. About half of the table is taken up with sizeof information, some
> of which could be expressed more concisely. (Are all Deb
On Tue, Jan 26, 2016 at 1:23:19 +, Ben Hutchings wrote:
> On Tue, 2016-01-26 at 12:16 +1100, Brian May wrote:
> > Ben Hutchings writes:
> >
> > > That's not the problem at all. Read the error message again. Read the
> > > source line it points to. Now look at where rv comes from:
> >
> >
Hi Sean,
On Sun, May 29, 2016 at 20:32:43 +0900, Sean Whitton wrote:
> Dear all,
>
> The Debian Haskell Group has picked a target set of package versions to
> freeze on for stretch. I'm working to upgrade packages in the DHG
> source package git repository to the target versions. This requires
99 matches
Mail list logo
