On Thu, 05 Jul 2018, Markus Schade wrote:
> Intel has released a new microcode version which includes the prerequisites
> for SSBD patches
>
> https://downloadcenter.intel.com/download/27945/Linux-Processor-Microcode-Data-File
>
> Contrary to what the download page says, this is the most recent v
On Sun, 29 Jul 2018, Riccardo Gagliarducci wrote:
> on Lenovo laptop ideapad 520 Gnome randomly crash and, after some seconds of
Are you using the latest version of the ideapad 520 firmware (BIOS/UEFI
and EC) ? If not, please upgrade it.
--
Henrique Holschuh
On Wed, 15 Aug 2018, Markus Schade wrote:
> Intel has released a new microcode version which includes updates for
> further CPU models providing the necessary code for SSBD as well as the
> recently disclosed L1TF vulnerability
>
> https://downloadcenter.intel.com/download/28039/Linux-Processor-Mi
On Fri, 17 Aug 2018, Moritz Mühlenhoff wrote:
> Have you been able to confirm (e.g. by testing) that 20180807 implements
> changes
> necessary for L1TF (such as L1D_FLUSH) or is there some official statement
> by Intel on this?
It does (privately tested on a few processor models). Exposes L1D_FL
On Sat, 18 Aug 2018, Ivan Baldo wrote:
> Do you have confirmation that they will change the license?
No. And apparently both SuSE and RedHat decided they are OK with the
new license or something (since they have updates on the works or
already available), so I will just ask them if they can s
On Thu, 23 Aug 2018, Markus Schade wrote:
> apparently Intel has changed its mind and is reverting to the old license:
>
> https://01.org/mcu-path-license-2018
> https://wccftech.com/intel-microcode-update-gag-order-benchmarks/
>
> But I guess we have to to wait for the actual MCU download to
> i
On Mon, 27 Aug 2018, Darius Spitznagel wrote:
> today I've installed intel-microcode (3.20180807a.1~bpo9+1) from
> stretch-backports to realize that firmware file "06-2c-02" is missing.
Refer to bug #907402
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907402
--
Henrique Holschuh
ecent x86 processors,
and ARM SoCs with crypto accelerators), I don't think the features
"rng-tools-old" implement are really relevant. I'd rather we had it in-kernel,
really.
--
Henrique de Moraes Holschuh
create. And the
one responsible for the broken NMU is, as far as I am concerned, owning
everyone a pack of beverages, since he is the one that should have cleaned up
the breakage he caused.
--
Henrique de Moraes Holschuh
severity 861169 important
retitle 861169 systemd service overrides opendkim.conf socket at start
thanks
The previous report mentioned by the bug submitter is #853769.
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769)
>From that bug report, message #38
(https://bugs.debian.org/cgi-bin/bu
ed in the command line may require
+overriding the systemd unit, but this is exactly as it works in
+sysvinit.
+
+ -- Henrique de Moraes Holschuh Sat, 11 Feb 2017 14:40:45 -0200
+
opendkim (2.11.0~alpha-9) unstable; urgency=medium
* Set umask to 0007 in opendkim.service so opendkim sock
On Sun, 05 Feb 2017, Brian May wrote:
> On Wed, Dec 07, 2016 at 09:26:04AM +0100, Jakub Novak wrote:
> > With the latest update of Debian packages in Scratch, Amavis started to
> > reject more than 50% of all emails as spam.
> > From Amavis debuging logs, all the MySQL fields that are of type "flo
On Sat, 11 Feb 2017, Scott Kitterman wrote:
> Please don't upload. I'll take care of it this week.
Ok. Thanks.
--
Henrique Holschuh
On Sun, 12 Feb 2017, Brian May wrote:
> I am starting to think that maybe the bug lies solely in p5-DBD-mysql
> not returning valid data.
I guess one could try to look at what it actually returns, comparing
4.037 (old API/ABI) with 4.041 (new API/ABI?), for the "string" return
type, I think. And
On Sun, 12 Feb 2017, Brian May wrote:
> >> https://github.com/perl5-dbi/DBD-mysql/issues/78
>
> Please read the latest message on the above report...
Jakub,
This issue is a nasty problem between amavisd-new and DBD-mysql. It is
yet not clear which program is at fault, or if it is an ABI break g
guration is done by that.
>
This could be quite relevant.
LOC, could you send (to this bug report) a dump of the *schema* for the
relevant tables (the ones returning 0 instead of the correct float) ?
Maybe ISPConfig is not creating them exactly the same way amavisd-
new would...
--
On Wed, 14 Mar 2018, Moritz Muehlenhoff wrote:
> On Sun, Jan 21, 2018 at 07:47:35AM -0200, Henrique de Moraes Holschuh wrote:
> > severity 887856 grave
> > block 887856 by 886998
> > thanks
> >
> > On Sat, 20 Jan 2018, Julien Aubin wrote:
> > > As of now
On Sun, 13 May 2018, Andreas Ziegler wrote:
> this bug's severity is marked "grave" but the changes haven't been
> backported to stable or oldstable yet.
>
> Is there a valid reason?
Sure. Nobody ever tell us it worked, so we don't fasttrack, which means
it will wait at *least* a couple months.
Intel has released several updates already, but not all of them AFAIK.
These microcode updates are of little impact until the kernel changes to
activate the new MSRs are deployed. But they do mess with conditional
jumps and LFENCE.
Anyway, uploading a partial, unofficial set of updates to unstab
On Fri, 05 Jan 2018, Louis-Philippe Véronneau wrote:
> Package: amd64-microcode
> Severity: grave
>
> It seems AMD cpus are also affected by the meltdown/spectre bugs.
Yes, they are, although just by Spectre as far as we know (i.e. not
affected by Meltdown).
> Do you know if AMD plans to release
Hi Louis-Philippe!
On Fri, 05 Jan 2018, Louis-Philippe Véronneau wrote:
> > No, we don't know if they will release it *only* to vendors for a
> > firmware update, or also for operating system updates. Also, for Zen
> > and later one cannot just hope to update microcode through the operating
> >
On Mon, 08 Jan 2018, Christoph Anton Mitterer wrote:
> Shouldn't that go to stable security updates as well?
The current plans are for stable to wait for Intel's official microcode
update pack.
It is not like this set of microcode updates will get you anything
without the kernel IBRS and IPBP sup
found 886806 intel-microcode/3.20140913.1
fixed 886806 intel-microcode/3.20180108.1
thanks
On Wed, 10 Jan 2018, Karl Kornel wrote:
> Well, it looks like there has been a release! The data file version is
> 20180108.
Due to timing, I missed this bug report when I readied the 3.20180108.1
package
Package: intel-microcode
Version: 3.20180108.1
Severity: grave
According to this:
https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/
and this far more helpful information:
https://pcsupport.lenovo.com/br/en/product_security/ps500151
A subset of systems with the
On Fri, 12 Jan 2018, Henrique de Moraes Holschuh wrote:
> Should you face issues with the new microcode (note: test it with an
> older kernel as well, since the current crop of new kernels are *ALSO*
> causing boot and resume-from-sleep issues that are completely unrelated
> to t
The VMWare KB52345 article at:
https://kb.vmware.com/s/article/52345
Includes an _incomplete_ list of signatures for the microcode updates
that are problematic in release 20180108:
Processor name
(non-exhaustive) signature stepping name
Intel Xeon E3-1200-v3,
Intel i3-4300,
Intel i
On Mon, 15 Jan 2018, Andreas Heinlein wrote:
> On Thu, 4 Jan 2018 23:18:49 -0200 Henrique de Moraes Holschuh wrote:
> > Intel has released several updates already, but not all of them AFAIK.
> >
> > These microcode updates are of little impact until the kernel changes to
>
Updated information from Intel:
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088
---8<---
Recommendations:
Status
Intel has made significant progress in our investigation into the
customer reboot sightings that we confirmed publicly last week
Intel has reproduced
severity 887856 grave
block 887856 by 886998
thanks
On Sat, 20 Jan 2018, Julien Aubin wrote:
> As of now intel-microcode of stretch is still set to 20170707 (20171117
> through
> bpo) which lets users vulnerable to Spectre attack CVE-2017-5715. Could you
> please bring quickly the microcode update
ebian.org alerts that the upload had reintroduced bugs in Trixie,
when I got your email on this bug report.
I have uploaded 3.20240813.2 a few minutes ago merging in the NMU changes and
hopefully fixing the oversight and closing this bug once again. Sorry about
that!
--
Henrique de Moraes Holschuh
> I cannot reproduce what you are describing. Could you please elaborate ?
Sure.
First, it happens on branches when using -j (some tag of head) -j (some
other tag of head).
First, I tried in a local repo, I didn't reproduce it, BUT I got something
weird from cvs status anyway, so here it is:
cv
tag 368681 = upstream
thanks
On Thu, 25 May 2006, Steve McIntyre wrote:
> I'm planning on digging into it further over the next couple of days;
> I'm very tempted to patch this change back out, if it is this
> simple...
Can we have a warning in place until then? Of course this bug should be
warni
On Thu, 25 May 2006, Steve McIntyre wrote:
> >Notice the file has a broken conflict, which is not detected by cvs status.
> >Nothing else detects it either, if I commit, I will commit a conflicted file
> >with conflict hunks.
>
> It seems this is a design decision by CVS upstream - see
>
> http
On Fri, 09 Jun 2006, Eric Christopherson wrote:
> Installing hplip fails because the init script fails. Transcript:
What errors are the hpssd and hpiod daemons reporting in /var/log/syslog ?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness
Package: sweep
Version: 0.8.4-2
Severity: grave
Justification: renders package unusable
There is no such package: libesd-also0
^
How did you even install this in your system before you uploaded? dpkg would
bitch about it and refuse to install the .deb...
And s
tag 350255 = moreinfo unreproducible
thanks
On Sat, 28 Jan 2006, Mark Hannessen wrote:
> I tried to compile the cyrus21-imapd source code by hand but ran into some
> trouble.
1. Did you clean the tree first (fakeroot debian/rules clean) ?
2. Did you verify whether dpkg-buildpackage works or not?
Package: adduser
Version: 3.82
Severity: grave
Justification: renders package unusable
Severity is set to grave because it breaks one of the two core
functionalities of adduser, and one that is used by most postinst scripts
that use adduser, to boot.
Adduser is failing to correctly deal with a pr
On Tue, 25 Apr 2006, Patrick Nijs wrote:
> Setting up sasl2-bin (2.1.19.dfsg1-0.1) ...
> Starting SASL Authentication Daemon: (failed).
> invoke-rc.d: initscript saslauthd, action "start" failed.
As usual, debhelper dislikes initscripts failing on upgrade even when it
should just ignore that.
Any
On Sun, 30 Apr 2006, Marco d'Itri wrote:
> > Please switch from libdb4.2 to the more recent libdb4.3.
> Please switch to libdb4.4 instead, which is the most recent release.
SASL is not stable with 4.4 in the version packaged for Debian. It may not
be either in the latest versions.
BDB breaks API
On Tue, 09 May 2006, Manolis Tzanidakis wrote:
> [20060509] Julien BLACHE <[EMAIL PROTECTED]> wrote:
> > At this point, we're running the backend, so the bug probably lies in
> > hplip. If possible, please provide a gdb backtrace so we can make sure
> > it really happens in the backend.
>
> I'm so
severity 366475 important
found 366475 hplip/0.9.7-4
clone 366475 -1 -2
onwer -1 !
owner -2 !
severity -1 wishlist
severity -2 wishlist
retitle -1 Please provide -dbg packages
retitle -2 Please provide -dbg packages
reassign -2 sane-backends
thanks
Severity downgraded as this does not affect many
On Sat, 13 May 2006, [EMAIL PROTECTED] wrote:
> E [13/May/2006:17:52:31 +0200] StartListening: Unable to bind socket for
> address 7f01:631 - Po?adovanou adresu nelze p?i?adit.
What's the result of
lsof -i -n | grep ipp
(or, if that returns nothing)
lsof -i -n | grep 631
in your box? If it
severity 367574 wishlist
tag 367574 wontfix
thanks
On Tue, 16 May 2006, Toni Mueller wrote:
> Version: 2.86.ds1-14
oldstable: 2.84-2woody1
stable: 2.86.ds1-1
2.84195 does not exist, so I assume you mean 2.84-1. This is a version
from 2001, probably released with oldstable before security updat
On Fri, 19 May 2006, Paul Menzel wrote:
> sudo /etc/init.d/hplip restart
> Stopping HP Linux Printing and Imaging System: hpiod hpssd.
> Starting HP Linux Printing and Imaging System: hpiod hpssd failed!
Check with ps auxwww if any of the HP daemons are still running after you
/etc/init.d/hplip st
On Mon, 22 May 2006, Paul Menzel wrote:
> hpssd was still running. After killing it, /etc/init.d/hplip start
> worked.
Ok.
> [ERROR]: Unable to connect to HPLIP I/O. Check and make sure HPLIP is
> running.
> [ERROR]: Unable to create client object.
Please send me the output of (run as root):
On Tue, 23 May 2006, Paul Menzel wrote:
> So as I see it, killing just hpssd and starting it manually lets
> hp-toolbox start. Then there is also something written in hpssd.port
> and .pid. (1)
>
> Killing hpssd and hpiod and starting both fails.
Hmm, add a "sleep 1" in the /etc/init.d/hplip scri
Package: cvs
Version: 1:1.12.13-2
Severity: grave
Justification: renders package unusable
CVS now cannot detect conflicted merges ("C" state) anymore, which is bound
to cause all sort of broken commits if people doesn't notice it in time.
I didn't actually *try* to commit a file with merge confli
reassign 341000 ftp.bugs.debian.org
severity 341000 important
merge 341000 340467
thanks
There is nothing I can do. Thanks for assigning 341000 to me :-) But
unfortunately this is a major testing fuckup and not something wrong with
the HPLIP packages.
On Sun, 27 Nov 2005, Aldo Maggi wrote:
> Pac
Package: sysfsutils
Version: 1.3.0-3
Severity: grave
Justification: renders package unusable
if [ "$f1" ] ;... is NOT valid shell syntax. Nor is [ ... -a "$f2" ].
You're missing a "-n" in front of all bare string tests inside [ ].
-- System Information:
Debian Release: testing/unstable
APT pref
severity 343854 important
thanks
On Sun, 18 Dec 2005, Giovanni Biscuolo wrote:
> Package: amavisd-new
> Version: 20030616p10-5
> Severity: critical
> Justification: breaks the whole system
As in it destroyed your harddrive, stopped the entire boot process or
somesuch? I seriously doubt so. Don'
Package: hplip
Version: 0.9.9-2
Severity: grave
Justification: maintainers do not want it in testing yet
HPLIP 0.9.10 has some issues that are still being addressed, and 0.9.9/0.9.8
are not stable. There are regressions too.
So, for the moment, I am blocking it from entering Debian testing.
--
On Mon, 17 Apr 2006, Brian May wrote:
> > "Justin" == Justin Pryzby <[EMAIL PROTECTED]> writes:
>
> Justin> amavisd fails to purge. This line fails:
> Justin> . /usr/share/debconf/confmodule
>
> What is the error you get?
And do you have debconf* packages installed? Which ones?
--
On Sun, 16 Apr 2006, Justin Pryzby wrote:
> dpkg: error processing amavisd-new (--purge):
> subprocess post-removal script returned error exit status 128
Exit status 128 is an unusual return status. Moreover, debconf should never
return it. WTF? 129 would be killed by SIGHUP, but 128 has no de
On Sun, 16 Apr 2006, Justin Pryzby wrote:
> debootstrap sarge .
> chroot .
> apt-get install amavisd-new
> sed -i s/sarge/testing/g /etc/apt/sources.list
> apt-get update
> apt-get install amavisd-new
> (This actually fails, deliberately I guess, in a fresh chroot, but didn't
> happen on my "workin
On Sun, 16 Apr 2006, Steve Langasek wrote:
> On Sun, Apr 16, 2006 at 10:09:06PM -0300, Henrique de Moraes Holschuh wrote:
> > On Sun, 16 Apr 2006, Justin Pryzby wrote:
> > > dpkg: error processing amavisd-new (--purge):
> > > subprocess post-removal script ret
On Sun, 16 Apr 2006, Henrique de Moraes Holschuh wrote:
> On Sun, 16 Apr 2006, Justin Pryzby wrote:
> > dpkg: error processing amavisd-new (--purge):
> > subprocess post-removal script returned error exit status 128
>
> Exit status 128 is an unusual return status. Moreover,
Package: libforms-dev
Version: 1.0-6
Severity: serious
Please change the package to install files on standard places. As this
package does not contain or use package-config or autoconf M4 macros,
packages that use it for building now fail (e.g. xwatch).
-- System Information:
Debian Release: tes
retitle 353702 hplib: hosed by libxft2/libfreetype6 braindamage
severity 353702 grave
tags 353702 confirmed etch
block 353702 by 350113
thanks
On Mon, 20 Feb 2006, Fred Ringwald wrote:
> Traceback (most recent call last):
> File "/usr/bin/hp-toolbox", line 41, in ?
> import base.async_qt as
Upstream has updated the KRGB patch to 1.2, and included a memory leak fix
too.
Here's the updated patch.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Ta
On Tue, 28 Feb 2006, Steve Langasek wrote:
> The Section: field of a Debian package's control file is a technical detail
> of the package, as is the location of a package on the Debian mirror. You
> may consider that a particular decision has political motivations, but this
> may be true of many t
On Wed, 01 Mar 2006, Steve Langasek wrote:
> On Wed, Mar 01, 2006 at 01:03:56AM -0300, Henrique de Moraes Holschuh wrote:
> > Otherwise, the ctte could overrule just about everything in Debian. Were
> > they not bound by the SC themselves, they could overrule even the SC itself
>
Package: openoffice.org-gcj
Version: 2.0.2-1
Severity: grave
Justification: renders package unusable
Setting up openoffice.org-gcj (2.0.2-1) ...
/var/lib/dpkg/info/openoffice.org-gcj.postinst: line 7:
/usr/lib/jvm/java-gcj/bin/gcj: No such file or directory
find: /usr/share/gcj-: No such file or
On Thu, 16 Mar 2006, Rene Engelhard wrote:
> Already reported as #357024, #357067. #357159, #357160 and #356984.
> Please check whether a bug already is reported before filing one,
I did, and none were reported at the time as far as "bts show" could tell.
--
"One disk to rule them all, One dis
On Thu, 16 Mar 2006, Rene Engelhard wrote:
> Henrique de Moraes Holschuh wrote:
> > On Thu, 16 Mar 2006, Rene Engelhard wrote:
> > > Already reported as #357024, #357067. #357159, #357160 and #356984.
> > > Please check whether a bug already is reported before filing on
reopen 375395 !
thanks
On Tue, 27 Jun 2006, Henrique de Moraes Holschuh wrote:
> I will close the bug report, then.
Sorry, I didn't notice it was being forwarded to udev. I am reopening the
bug...
--
"One disk to rule them all, One disk to find them. One disk to bring
them a
On Wed, 28 Jun 2006, Kenshi Muto wrote:
> > IMHO it is a udev issue. On an i386 unstable system I've just
> > checked, it's loading parport and parport_pc, but not lp. This is a
> > bog standard PIII with an Intel 440BX chipset. It must have detected
> > the parallel port in order to load the pa
On Wed, 28 Jun 2006, Roger Leigh wrote:
> I just installed discover on my i386 test system, and it didn't load
> lp. I rebooted it to see what happened at startup, and it didn't load
> lp then, either.
Please file a bug against discover, it has to auto-detect the need for lp
and other very common
On Wed, 28 Jun 2006, Martin-Éric Racine wrote:
> We have too many hardware detection layers and none of them able to see
> the full picture. Even worse, as witnessed in this particular case, they
> all fail at detecting something as simple as the printer driver.
>
> Anyhow, udev and discover dupli
On Wed, 28 Jun 2006, Martin-Éric Racine wrote:
> > I have seen the other messages (discover, ...) but I want to answer this
> > mail
> > anyway.
> >
> > How do I get the udev bootup output? What else (discover, ...) can I test
> > to
> > help fixing this bug?
>
> As pointed out by Henrique an
Let's go over the way things work, and see how we can fix them back so that
they work correctly. Please bear with me while I go over the entire
problem, and feel free to correct any mistakes I make.
Reading manpage tzset(3) before you read any further is advised.
AFAIK There are ONLY TWO valid m
Please remember this is bug is being dealt with with util-linux perspective
when reading my answers...
On Sun, 01 Jan 2006, Nate Eldredge wrote:
> Right. Which is kind of painful in the daylight savings case. I can't
Correct. It is *flat out impossible* to fix this issue completely (as in do
e
tag 342887 + patch
thanks
See attached patch. It was not completely tested yet, but it seems sane,
and it survived some light testing.
Note that hwclock.sh runs much later than I'd like it to, but we need to
make sure /usr is mounted, and that means it must run after NFS has had its
change of mo
On Fri, 06 Jan 2006, Wouter Verhelst wrote:
> I just noticed that my laptop, at bootup, started an fsck for the root
> filesystem, claiming that it was a filesystem with errors. When it was
> about 20% done, it exited, and told me to rerun it manually. I expected
> a prompt for my root password and
On Mon, 09 Jan 2006, Adeodato Simó wrote:
> Finally, if there's a strong reason for which your package should not
> be NMUed, please note so in this bug report. Prospective NMUers will
> read your reasoning, and will decide if it's strong enough to delay
> their upload.
NMUs are welcome, i
On Sun, 08 Jan 2006, Steve Langasek wrote:
> The diff includes one change not directly related to xlibs-dev, but which I
> noticed in the process of identifying the new build-depends: when I noticed
> the package build-depends on libxaw8-dev while I still have libxaw7-dev on
> my system, I was tol
On Thu, 12 Jan 2006, Martin Stolle wrote:
> The only valid solution is to copy the appropriate timezone info to
> /etc/localtime. Rerunning tzconfig or recopying this file when
That's what will be done, when we prove it to the glibc people that it is
save (i.e. please do so on your system, and re
Package: gtklookat
Version: 0.13.0-1
Severity: grave
Tags: sid
Justification: renders package unusable
This package needs to go through the C++ transition, and rebuild against
the new openvrml libraries.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy:
On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
> It is *absolutely intolerable* to declare such conflicts for shared
> libraries, where there are easy solutions: MAKE TWO LIBRARIES THAT
> HAVE DIFFERENT NAMES.
The package has to build libraries with differently versioned symbols as
well, to avoid
On Sun, 11 Sep 2005, Domenico Andreoli wrote:
> On Sun, Sep 11, 2005 at 10:54:17AM -0300, Henrique de Moraes Holschuh wrote:
> > On Sat, 10 Sep 2005, Thomas Bushnell BSG wrote:
> > > It is *absolutely intolerable* to declare such conflicts for shared
> > > libraries, whe
Package: openssl
Version: 0.9.8-2
Severity: critical
Justification: breaks unrelated software
OpenSSL does not version symbols. This means all applications that somehow
end up linked to both openssl 0.9.7 and 0.9.8 segfault or behave otherwise
erratically (which would be a critical bug by itself,
On Mon, 17 Oct 2005, Debian Bug Tracking System wrote:
>* include symbol versioning in Configure (closes: #330867)
Thanks!
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." --
Package: bsmtpd
Version: 2.3pl8b-16
Severity: grave
Justification: causes non-serious data loss
sbsmtp will gladly ignore any error-exit status codes from UUX, and proceed
to act as if mail was corretly delivered.
If backups are enabled, that means the batch ends up in the bak dir for a
while, if
On Tue, 16 Aug 2005, Roland Rosenfeld wrote:
> I fully agree with you. I suggest to put bsmtpd itself in the
> bitbucket. The code is quite old, hard to read and every time I look
> deeper into it, I find some problems in the code like above.
Ok. I am going to revert to my shell scripts, which
severity 326684 important
thanks
On Mon, 05 Sep 2005, Per-Arne Hellarvik wrote:
> Package: hplip
> Version: 0.9.4-3
> Severity: grave
> Justification: renders package unusable
Watch the bug severity inflation. Grave is for bugs that make it unusable
for everyone, and rebuilt packages certainly d
On Thu, 24 Mar 2005, Josselin Mouette wrote:
> > I'm not sure what to do now. Is it possible to link our wxgtk2.4 against
> > glib2.0? Or unlink libsdl from using libglib?
>
> I'm afraid there is no miracle solution. Getting wxgtk2.5 to install
Miracle? no. Technical, sound, and sane? Yes: Versi
Package: kernel-tree-2.6.11
Version: 2.6.11-1
Severity: grave
Tags: security
Justification: user security hole
As usual. I feel weird filling what used to be a wishlist-level report as
grave, but...
Summary of changes from v2.6.11.5 to v2.6.11.6
==
Ch
On Wed, 30 Mar 2005, Horms wrote:
> With the exception of the load_elf_library problem,
> which I will check on now, I believe I have patches for
> the rest in SVN as neccessary for:
I have checked 2.6.11 (looked it over, I am not running 2.6.11 here yet),
and it looks OK. It would be a very good
On Wed, 30 Mar 2005, Horms wrote:
> > with 2.6.11.X, including the numbering (i.e. next upload should be
> > kernel-source-2.6.11, package version 2.6.11.6-1).
>
> I agree it would be good to sync up the patches,
> but I don't think there is any need to include the
> .6 in the debian version as we
On Wed, 30 Mar 2005, Horms wrote:
> > It is much more user-friendly, and it readly provides information on the
> > most up-to-date tree it was synced with, in aptitude/dselect/synaptic...
>
> Yes, but the problem is that each time it changes backages
> have to go through a NEW cycle.
I assume you
Package: libsnmp5-dev
Version: 5.1.2-6
Severity: grave
Justification: renders package unusable
Do *NOT* play with prefix= in make install when using autoconf+libtool,
whatever you put in there will end-up in .la files, and break everything
that needs your library and uses libtool.
$cat /usr/lib/l
tags 302195 + patch
thanks
See attached patch that does a quick fix of the mess.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
d
On Wed, 30 Mar 2005, Stephen Gran wrote:
> INSTALL_PREFIX appears to be respected. So this would be the right fix,
> it seems.
I tested with DESTDIR, and that broke. If INSTALL_PREFIX works, and it is
not ending up in the .la files (or elsewhere), than yes, your fix is much
better.
--
"One di
On Wed, 30 Mar 2005, Stephen Gran wrote:
> Well, the maintainer has two patches now, so hopefully this can be fixed
> soon enough with one of them.
And, if he does not, I will NMU using the safest path (my fix-the-la-files
patch), which can't break anything worse than what we currently have.
Expe
On Thu, 31 Mar 2005, Jochen Friedrich wrote:
> > Expect an NMU uploaded to 5-DAY in the next 24h if the maintainer does not
> > reply to this bug. After the upload, he will still have 5 days to remove
> > the NMU from incoming, or to upload a new version of the package (which
> > would invalidate
1) unstable; urgency=emergency
+
+ * NMU (with permission from maintainer)
+ * debian/rules: clean up libdir in all .la files installed to
+/usr/lib, so as to avoid breaking all libtool builds (closes: #302195).
+
+ -- Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Thu, 31 Mar 2005 12:14:11
Package: openmsx
Severity: grave
Justification: renders package unusable
openmsx depends on libgcc1 (>= 1:4.0) which is NOT in sid.
Please build it using gcc 3.4 in a sid chroot.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386
Package: cupsys
Version: 1.1.23-8
Severity: grave
Tags: sid
Justification: renders package unusable
Setting up cupsys (1.1.23-8) ...
error in control file: `Section' value not specified at
/usr/sbin/install-docs line 606, line 7.
dpkg: error processing cupsys (--configure):
subprocess post-insta
s in clean rule
+
+ -- Henrique de Moraes Holschuh <[EMAIL PROTECTED]> Sun, 17 Apr 2005 21:13:40
-0300
+
xfmail (1.5.5-2) unstable; urgency=low
* Use $LD instead of "$LD" inside configure so the shell will find
diff -ruN xfmail-1.5.5/debian/control xfmail-1.5.5-2.1/debia
Package: ftp.debian.org
Severity: grave
Justification: the package is useless
Please remove cyrus-sasl and all its binary packages from sid.
After NMUing it a lot of times, and giving both the public (via email to
d-devel and d-user) and the almost-MIA maintainer more than 3 months to
speak up ag
On Mon, 18 Apr 2005, Steve Langasek wrote:
> > 2) Any idea why ${shlibs:Depends} does not include libsaslX?
>
> Because the above check is wrong: the xfmail binary is *not* linked against
> libsasl.
Oh.
> $ objdump -p /tmp/xfmail/usr/bin/xfmail | grep NEEDED
> NEEDED libmail.so.0
> NEED
1 - 100 of 244 matches
Mail list logo
