Package: firefox-esr
Version: 115.7.0esr-1
Severity: normal
Dear Maintainer,
For some reason my `firefox-esr` is refusing to show me some pages.
Most pages work fine, but some give me the dreaded "Gah. Your tab just
crashed".
Two example URLs which suffer this fate are:
> Please work on the already existing (and patched!) chromium in the archive
> instead of adding one additional chromium-based browser that then also lacks
> team power. If you need any additional patches on Debian's chromium that are
> in ungoogled chromium, make them available in Debian's
Package: linux-headers-amd64
Severity: normal
Dear Maintainer,
I've been using a i386 install running on an amd64 kernel for many
years, and recently a new problem showed up: to build kernel modules
`dkms` needs `linux-headers-amd64(:amd64)` and this package conflicts
with the 32bit GCC
Oh, and I finally did manage to recover the output where I noticed the
problem (from a script which runs debdelta-upgrade` followed by
`aptitude upgrade`):
[...]
Recreated debs are saved in the directory /var/cache/apt/archives
Deltas: 1 present and 0 not,
Package: debdelta
Version: 0.67
Severity: normal
Dear Maintainer,
I happened to notice that after debdelta created a deb file for libzbar0,
`apt` downloaded it nevertheless.
So I went to check /var/cache and sure enough:
% l /var/cache/apt/archives/libzbar0_0.23.92-7*
-rw-r--r-- 1 root
> Xorg refuses to work on my Thinkpad X201s nowadays, tho it used to work just
> fine a year or so ago. Wayland still works fine.
> The observed behavior is that when GDM3 starts up (using Xorg because
> I have set `WaylandEnable=false` in its config file) at the end of the
> boot process, the
Package: xserver-xorg-core
Version: 2:21.1.10-1
Severity: normal
Dear Maintainer,
Xorg refuses to work on my Thinkpad X201s nowadays, tho it used to work just
fine a year or so ago. Wayland still works fine.
The observed behavior is that when GDM3 starts up (using Xorg because
I have set
> 2) if there is no delta, it will "download" the new package (this may be
>because, the delta was too big, or the package was too small, or, some
>error)
> 3) after all available deltas have been applied, it may exit, or continue
> downloading all needed new .deb
> This behavior can be
> debpatch and debdelta-upgrade have an option
> --format unzipped
> that will recreate the deb w/o compressing the data part: this is
> much faster.
But it would often use a lot more disk space :-(
If we were instead to just keep the original `.deb` together with the
xdelta, it would be in most
Subject: debdelta: Avoid generating the actual `.deb`
Package: debdelta
Version: 0.67
Severity: wishlist
Dear Maintainer,
`debdelta-upgrade` is great at reducing the amount of data downloaded,
but on some of my (weaker) machines, generating the `.deb` files takes
a lot of time, and for no good
Subject: debdelta: Improve performance info
Package: debdelta
Version: 0.67
Severity: minor
Dear Maintainer,
I'm very happily using `debdelta-upgrade` now that I finally heard about
it (I've been using Debian for 20 years and wishing for something like
DebDelta for a big part of it), so first:
> I'd go so far to think that this is not constrained to i386 binaries on
> amd64 hosts. `aplay /dev/zero` segfaults on a plain i386 host with asound
> 1.2.10. Downgrading to 1.2.9 helps.
Is this the same as https://github.com/alsa-project/alsa-lib/issues/352 ?
Stefan
>> Stefan "dreaming of Debian updates as efficient as
>> `git fetch` :-)"
> You are not the first one, who complains and (probably) not the last
> one. Due to the limited man power in the team, we simply copy the
> packaging scheme given by TeX Live upstream and this is
Package: texlive
Version: 2023.20230613-3
Severity: wishlist
Dear Maintainer,
This is not a new problem, but after all these years I figured maybe
I should finally report it: I think updates to Texlive are larger than
they should. This is probably not completely specific to Texlive but
that's
Working great again, thank you!
Stefan
Debian Bug Tracking System [2023-09-14 18:03:06] wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the texlive-binaries package:
>
> #1051282: texlive-binaries: Can't install without SSE2 on i386
>
>
> since the wrong package: linux-compiler-gcc-13-x86
> is isntalled.
Thanks... so this prompted me to dig again into the problem and this
time I found a workaround which consist in installing
`gcc-13-x86-64-linux-gnu` (which I found simply via `apt-file search
/usr/bin/x86_64-linux-gnu-gcc-13`.
Ping?
Any idea what change might have caused this? It worked fine for kernel 6.1.0-7.
Stefan
Stefan Monnier [2023-08-03 18:37:23] wrote:
> Package: dkms
> Version: 3.0.11-3
> Severity: normal
>
> Dear Maintainer,
>
> My machine is running Debian testing i386 but
Package: texlive-binaries
Version: 2022.20220321.62855-8
Severity: normal
Dear Maintainer,
Apparently bug#1035461 is back. `apt show texlive-binaries/testing`
shows:
Package: texlive-binaries
Version: 2023.20230311.66589-3
[...]
Depends: [...] sse2-support [...]
Any chance
Package: dkms
Version: 3.0.11-3
Severity: normal
Dear Maintainer,
My machine is running Debian testing i386 but with an amd64 kernel
(to make better use of my 8GB of RAM). I also have `dkms` and `tp-smapi-dkms`
installed.
Until recently this worked fine and built the `tp-smapi` kernel module
code that uses SSE2 instructions, so `texlive-binaries` was changed to
require `sse2-support`.
>> Hmm, so SSE2 is not a requirement on Debian?
No, indeed. And the `sse2-support` package is the embodiment of this fact.
There's a fairly good reason why SSE2 is not a requirement:
The
>> In bug#1023007, we discovered that `luatex`'s JIT compiler generates
>> code that uses SSE2 instructions, so `texlive-binaries` was changed to
>> require `sse2-support`.
>>
> As I understood the situation it is not luatex, which does not work on
> your computer, but just the luajit... variants.
Package: texlive-binaries
Version: 2022.20220321.62855-5
Severity: wishlist
Dear Maintainer,
In bug#1023007, we discovered that `luatex`'s JIT compiler generates
code that uses SSE2 instructions, so `texlive-binaries` was changed to
require `sse2-support`.
This was a quick way to avoid the
Timo Aaltonen [2023-03-09 08:50:09] wrote:
> Stefan Monnier kirjoitti 9.3.2023 klo 0.18:
>> Control: found -1 2:21.1.7-1
>> I still see this problem with the latest version on `testing`.
> I'm sure the problem is in the kernel driver (i915) and not xserver.
In that case, the ke
Control: found -1 2:21.1.7-1
I still see this problem with the latest version on `testing`.
Stefan
Stefan Monnier [2022-09-21 16:02:47] wrote:
> Jakub Wilk [2022-02-11 23:17:58] wrote:
>> After recent upgrades, the X server no longer works for me: I get only
>> blan
> Just to be clear, this condition should be checked before emacs is
> willing to use the temporary directory in question. No unprivileged
> user should be able to overwrite a directory entry the uid of the
> emacs process creates at any point in the path to the temporary file.
AFAIK we usually
> Before e6043641d30 the file was created by Fmake_temp_file_internal and
> afterwards overwritten by libgccjit.
Yes, that was good.
> So I guess one could remove the file after the first creation and make
> it a link pointing to some other file waiting for libgccjit to do
> its write.
"One" as
>> `make-temp-name` uses `O_EXCL | O_CREAT` so as to close the race
>> condition: if someone predicated the filename, we detect it atomically
>> and we try again.
>>
>> You might like to check
>>
>>
>>
> Shouldn't make-temp-file-internal return a non predictable file name?
Nope. It's less predictable but it's still predictable.
> Otherwise what's the point of using make-temp-file in the first place if
> the temporary name is predictable?
`make-temp-name` uses `O_EXCL | O_CREAT` so as to
Oh, it's worse: I installed `picom` which made the opacity slider work,
but that affects the whole window, whereas I only want the background to
be transparent.
Along the way I noticed another problem with the opacity compared to the
old code that relied on the "Shape" X11 extension: even if I
Package: xdaliclock
Version: 2.44+debian-2
Severity: normal
The version of xdaliclock in Debian testing seems to be quite different from
the version I've been running for the last ... 20 years(?). The most obvious
difference is that it disregards my Xresource settings.
But more importantly, I
Jakub Wilk [2022-02-11 23:17:58] wrote:
> After recent upgrades, the X server no longer works for me: I get only
> blank screen. Worse, the blankness remains even after I zap the server.
> Downgrading xserver-xorg-core to 2:1.20.14-1 fixed it for me.
I'm not sure if I suffer from the same
> I just tried to upgrade my `testing` installation but the problem is
> still present. Did you install the patch there?
I just upgraded to the new `bullseye` release and the problem is
still there.
Stefan
Julien Cristau [2021-03-18 14:58:30] wrote:
> On Thu, Mar 18, 2021 at 09:39:36AM -0400, Stefan Monnier wrote:
>> > I tried to reconstruct the given backtrace in [1].
>>
>> Thanks,
>>
>> > So the actual issue seems to be a "movq" instruction whi
> I tried to reconstruct the given backtrace in [1].
Thanks,
> So the actual issue seems to be a "movq" instruction which
> seems to be due to [3] a SSE2 instruction, which might
> the "Pentium III M" is lacking, like Stefan already noted.
> I am not sure where the current Debian baseline could
> My Thinkpad X30 uses Debian testing and after a recentish update (a couple
> months ago) the X server doesn't want to start any more.
>
> As you can see in the Xorg.0.log below, it fails with an "Illegal
> instruction".
> This machine is admittedly old, so I suspect it might have to do with the
> One of our VPN users encountered the same issue on Ubuntu 20.04, which lead
> us to investigate this. The cause of this issue is netscript-2.4[1], a rather
> old and obscure alternative ifup/ifdown implementation. In its default
> configuration a netscript systemd service instance is
Package: mpd
Version: 0.21.5-3
Severity: normal
Dear Maintainer,
I'm pretty sure this is not a bug in MPD but probably in some of the
libraries it uses (libresample, maybe?).
Usually, when playing 44.1kHz flac files on my ARM SoC based on
Allwinner A10 (with one ARM Cortex A8), the CPU use of
Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20200714-1+b1
Severity: important
Dear Maintainer,
My Thinkpad X30 uses Debian testing and after a recentish update (a couple
months ago) the X server doesn't want to start any more.
As you can see in the Xorg.0.log below, it fails with
Package: network-manager
Version: 1.26.0-1
Severity: normal
Dear Maintainer,
All my Debian machines are much slower at reconnecting to the
local network than other machines (be they smartphones, tablets,
or laptops using proprietary OSes).
Here's what I see in the NM applet in the XFCE4 panel,
Package: gkrellm
Version: 2.3.10-2+b1
Severity: important
Dear Maintainer,
`gkrellm` stopped working a while back for me (can't say for sure when it
started).
It crashes soon after displaying its window for me. The error message is:
% /usr/bin/gkrellm --sync
The program 'gkrellm'
>> An article I was working on started to throw me lots and lots of errors and
>> not
>> generating any PDF when passed to `pdflatex` after the last upgrade of
>> Texlive.
[...]
> https://tex.stackexchange.com/questions/550158/undefined-control-sequence-in-expl3
>
> says that it could be caused
Package: texlive-latex-recommended
Version: 2020.20200629-1
Severity: important
Dear Maintainer,
An article I was working on started to throw me lots and lots of errors and not
generating any PDF when passed to `pdflatex` after the last upgrade of Texlive.
I reduced the problem to the followint
> it worked for me, because I have a separate /boot partition. After
> changing the uuid of /boot, the machine does not boot.
>
> But IMO it's a problem of grub, using this sort of code in grub.cfg:
>
> if [ x$feature_platform_search_hint = xy ]; then
> search --no-floppy --fs-uuid --set=root
> I justs tested dracut with this in the kernel cmdline:
> root=/dev/mapper/vg1-root
> Works without any problems.
But have you tested it with a disk that has different UUIDs?
I just tried
# lsinitrd /boot/initrd.img-5.3.0-2-armmp| grep by-uuid
-rw-r--r-- 1 root root 146
>> FWIW, I have 3.19.8+dfsg0-7 installed and am still seeing this problem.
> Knowing the printer model is always useful.
HP-Deskjet-5150
> The file /usr/lib/os-release has bullseye/sid in PRETTY_NAME. Edit
> bullseye/sid to reduce the number of characters to less than 12.
> Does this have any
> That'll be 3.19.8+dfsg0-4, uploaded later tonight. It will also ship
> autopkgtests, to also test hplip printing on fake printers.
FWIW, I have 3.19.8+dfsg0-7 installed and am still seeing this problem.
Stefan
Package: gdm3
Version: 3.30.2-3
Severity: important
Dear Maintainer,
After the upgrade to Buster, I'm unable to get GDM3 working on this system (a
thinkpad X201s).
It fails at start. I tried to change /etc/gdm3/daemon.conf to prevent use of
Wayland,
but it made no noticeable difference.
I
> I tried both of the fixes mentioned in messages #70 and #75. They both
> worked for me. Thanks everyone!
I just bumped into this bug on Debian stable (I suspect that it appeared
when I updated from 10.0 to 10.1). I had
# cat /home//.config/xfce4/helpers.rc
FileManager=nautilus
Ping?
Stefan
Stefan Monnier writes:
> Ping?
>
> Still seems to be the case with version 52.8.0
>
>
> Stefan
>
>
> Stefan writes:
>
>> Package: firefox-esr
>> Version: 52.3.0esr-2
>> Severity: normal
>>
>> Dear Ma
Package: openvpn
Version: 2.4.7-1
Severity: normal
Dear Maintainer,
My OpenVPN client setup just stopped working, maybe/likely linked to a recent
update of Debian (testing).
The end result is that the openvpn daemon looks happy and gives me the right
syslog messages, yet the interface gets no
>> This bug basically makes the package unusable.
> Unfortunately that's true.
>> I understand that adapting the packaging to the new structure of
>> Zotero-5 will take some time, but in the mean time, could someone add
>> a page to the Debian wiki outlining how to install Zotero-5 by hand on
>>
> usage of parallel requires agreeing to a click-wrap that is inconsistent
> with the DFSG. it should be moved to non-free
[...]
> parallell --bibtex:
> "When using programs that use GNU Parallel to process data for publication
> please cite:
> ...
> Or you can get GNU Parallel without this
Package: tor
Version: 0.2.9.15-1
Severity: normal
Dear Maintainer,
I installed Tor on my machine and haven't made any change to its config yet,
as far as I know.
But when I start it, AppArmor seems to stop it right at the start.
More specifically, I get:
# /etc/init.d/tor stop
[ ok ]
> > specifies the root partition via "root=/dev/mapper/VG-root" so there's
> > no need for any UUID to find the root partition. And since dracut
> > is not configured in "hostonly" mode, I did not expect any problem.
> Please try to use root=LABEL=.
> and see if this helps.
I
Package: dracut
Version: 044+241-3
Severity: normal
Dear Maintainer,
The HDD on my little BananaPi homeserver is dying (keeps giving errors
causing SATA coection reset, etc...), so I took it out and plugged
in another HDD that contained a backup copy of the system (basically
and `rsync` of
Ping?
Still seems to be the case with version 52.8.0
Stefan
Stefan writes:
> Package: firefox-esr
> Version: 52.3.0esr-2
> Severity: normal
>
> Dear Maintainer,
>
> In older versions of Firefox, the dialog box which asked me whether
> I want to downoload the file or pass it to some
Ping?
Stefan
Stefan Monnier <monn...@iro.umontreal.ca> writes:
> Package: mupdf-tools
> Version: 1.12.0+ds1-1
> Severity: normal
>
> Dear Maintainer,
>
> Recently, Emacs's doc-view-mode started failing for me in some cases.
> After tracking down the o
Package: mupdf-tools
Version: 1.12.0+ds1-1
Severity: normal
Dear Maintainer,
Recently, Emacs's doc-view-mode started failing for me in some cases.
After tracking down the origin of the problem, it seems to be due to
a problem in `mutool`.
I can reproduce it with:
mutool draw -o foo.png
> This is still an issue in Debian stretch: the gdm3 package runs
> pulseaudio, which takes over the bluetooth device and makes it
> impossible for regular users to connect to their bluetooth device
> using the hifi A2DP sink. See #805414 for more details on that
> side. There's a workaround for
Package: cups-browsed
Version: 1.20.1-1+b1
Severity: normal
Here's a sample session:
# ps auxw|grep cups
root 27143 0.0 0.1 19508 9600 ?Ss Apr040:07
/usr/sbin/cupsd -l
root 27144 0.0 0.1 42080 11184 ?Ssl Apr04 0:00
/usr/sbin/cups-browsed
> So I cannot reproduce your problem. I suppose disconnecting the ethernet
> connection doesn't do anything for you?
No, indeed: using only the ethernet or only the wifi connection doesn't
make any difference (usually only the ethernet is up).
> > Avahi Resolver: Service 'HP OfficeJet Pro 8100
> Thank you for thinking to send the log. There are three devices with IP
> addresses which cannot be found. Are they all printers?
Only the HP-8100 is a real printer. The other two are advertised by
some laptop which happened to be connected.
> Does Evince show them all?
Yes.
> Please do
>
> Tentatively, this looks more like a cups-browsed issue.
>
> /etc/cups/cups-browsed should have a line "BrowseRemoteProtocols dnssd cups".
Yes, I have that.
> Try uncommenting "LogDir /var/log/cups" and "DebugLogging file" and look
> at /var/log/cups/cups-browsed_log after restarting
>> I have a printer connected via USB to a local server (running Debian
>> stable as well). This printer is made visible to my clients by
>> running cups-browsed.
> For the server to advertise its printers with DNS-SD cups-browsed is
> superfluous.
I expressed myself poorly: the cups-browsed is
Package: cups
Version: 2.2.1-8+deb9u1
Severity: normal
Dear Maintainer,
I have a printer connected via USB to a local server (running Debian stable as
well). This printer is made visible to my clients by running cups-browsed.
My clients have no locally-configured printers (and hence no
> Just to be clear, this is not in Debian main, it is in contrib.
Thank you very much for that. Happily running it on my BananaPi here now.
What is its status exactly: I see "contrib" described as "free but
depending on non-free code", but it's not clear exactly what non-free
code it relies on.
I haven't seen any reaction to this.
Other than "mere users like us complaining", is there a plan?
Stef
> On a system with systemd, dnsmasq and resolvconf installed, the
> /etc/resolvconf/update-libc.d/squid3 hook prevents dnsmasq from
> starting. As far as I can see, the problem is caused by a deadlock of
> "systemctl start dnsmasq.service" in conjunction with "systemctl
> reload squid3.service".
> Don't know why but my PPP interface sometimes isn't working right away and
> needs some time to settle, so sometimes when ddclient runs from
> /etc/ppp/ip-up.d/ddclient it is unable to set the new IP.
> My workaround was to add a "sleep 3" in /etc/default/ddclient.
I see the same problem
Package: xwayland
Version: 2:1.17.3-2
Severity: normal
Dear Maintainer,
I see that Wayland is now used by default in Debian testing.
While trying to figure out why it happens not to work for me
(which may lead to another bug report) I found that there is
very little (if any) documentation about
Package: gnome-terminal
Version: 3.18.1-1
Severity: normal
Dear Maintainer,
I use this machine both with Gnome and XFCE, depending on which user is logged
in. My /etc/alternatives/x-terminal-emulator points to /usr/bin/gnome-
terminal.wrapper.
When I log into XFCE and try to open a terminal it
Package: general
Severity: wishlist
Dear Maintainer,
I've been using Debian on all my machines for many years and am generally very
happy with it but I recently realized that my experience could have been even
better (both for me and for the maintainers of all the packages I use) if it
were
Package: apt
Version: 1.0.10.2
Severity: normal
Dear Maintainer,
If I run "apt-get update" (or "aptitude update") when the network is down (or
the proxy is unavailable), APT forgets everything instead of keeping using the
old data.
E.g. if I "Disconnect" the netowrk and run the following
Have you tried the solution from #709117?
I already have dev.cdrom.lock=0 in my sysctl, yes.
Also, I don't see anything like
19:33:17 T:140173220951968 DEBUG: ExecuteXBMCAction : Translating
EjectTray()
19:33:17 T:140173220951968 DEBUG: ExecuteXBMCAction : To EjectTray()
in my
Have you tried the solution from #709117?
I already have dev.cdrom.lock=0 in my sysctl, yes.
Also, I don't see anything like
19:33:17 T:140173220951968 DEBUG: ExecuteXBMCAction : Translating
EjectTray()
19:33:17 T:140173220951968 DEBUG: ExecuteXBMCAction : To EjectTray()
in my log.
http://cgit.freedesktop.org/systemd/systemd/tree/TODO?id=HEAD#n562
This points to line-number 562 in a long TODO list. Of course, the item
at that line number is unrelated to this bug-report (tho I presume it
was related back when this reply was sent).
I think this is a very nasty regression
Package: xserver-xorg-video-modesetting
Version: 0.9.0-1+b1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
*
Is there anything that uses imap.el? I thought it was obsolete...
Should we move it to lisp/obsolete, then?
Stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[When possible, please preserve the -forwarded address in any replies.]
The following issue was just reported against emacs23 in Debian, and
from a quick glance, it looks like 24.4 still uses s_client, so if this
is a problem, it's perhaps still relevant.
AFAIK, nowadays Emacs only use
fixed in Emacs trunk bzr 111064; see Bug#13054 http://bugs.gnu.org/13054.
This fix is in the next Emacs release, and the fix should be easily
Hmm... if it's in trunk it's not going to be in 24.4, so not in the next
release, right?
Stefan
--
To UNSUBSCRIBE, email to
[If possible, please preserve the -forwarded address in any replies.]
This 24.3 crash was reported to Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732029
I thought I'd pass it on for a look, though I'm not sure there's enough
information for diagnosis.
Indeed, there's not
It appears that Emacs 24.3 is crashing on Debian mipsel, though it's not
clear whether it's an Emacs problem, a toolchain issue, or something
else.
Could you check whether the same problem shows up for the 24.4 pretest
(i.e. 24.3.93)? Also, worthwhile would be to test to see if building
with
Why should we only take blink-cursor-mode from there, and ignore all
the rest?
Nobody asked to ignore the rest ;-)
E.g., cursor-blink-time and cursor-blink-timeout. And then
there are other settings, like cursor-size, clock-format, etc. It
makes very little sense to take only one setting.
In the GTK+ version of Emacs, the default setting for
blink-cursor-mode should respect the desktop setting of
org.gnome.desktop.interface.cursor-blink . An explicit setting of
blink-cursor-mode in .emacs could still override it, but the default
setting should not.
That would make a lot of
In the GTK+ version of Emacs, the default setting for
blink-cursor-mode should respect the desktop setting of
org.gnome.desktop.interface.cursor-blink . An explicit setting of
blink-cursor-mode in .emacs could still override it, but the default
setting should not.
That would make a lot of
Exactly. I hope the reasoning behind current defaults has been explained
adequately.
Not sure what you mean by adequately. I understand your argument, but
I disagree with it. Do you understand my argument?
That said, it would be great to improve reporting if something like this
happens.
Yes, you can configure such behaviour.
I already have plenty of ways to configure the behavior I need.
This discussion is about the default behavior.
Stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
- If a mount fails, keep on booting. And then do your best to try and
bring this problem to the attention of someone (mentioning the
nofail option in that same message). Only stop the boot if the
partition is explicitly marked as critical or stoponfail.
Well, 'fail', which is the default,
In which way is it safe and correct to interrupt the boot in this case?
In the way that missing some mounts may indicate a serious problem and
could lead to incorrect behaviour or data loss.
Haven't heard many complaints about that over the years, so it shouldn't
be a super-top-priority goal,
\RequirePackage{pst-ovl}
Indeed. But since seminar is just one package, and we don't want to
pull in unconditionally texlive-pstricks into texlive-latex-recommended,
I made it a suggests.
I'm not sure I understand. AFAICT, `seminar' is 100% unusable without
texlive-pstricks, so if you don't
Well, I consider the sysvinit behaviour buggy and unfortunately this
lead to broken fstab configurations in the past.
There are 2 changes here:
1- systemd seems to *wait* for the device to be available, whereas the
old scripts just failed right away if the device was absent.
2- if the mount
Package: texlive-latex-recommended
Version: 2014.20140717-01
Severity: normal
Dear Maintainer,
If you install . but no texlive-pstricks, and then try to run pdflatex on a
file that starts with
\documentclass[display,semhelv]{seminar}
pdflatex stops right away with:
(./slides.tex
Control: tag -1 + moreinfo
Hi,
I can't remember seeing this problem recently, so maybe it's OK now.
It's not like I could reproduce it on demand, tho,
Stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
If the problem continues with the new version, can you try if the
problem happends:
I've fixed it locally years ago with the patch I sent.
Haven't seen the problem since,
Stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Yes, but I don't see how emacsen-common could know that, and as far as I
understand things, a successful exit from a dpkg run is supposed to
indicate that everything's fine.
And as a general, rule when Elisp's byte-compilation signals an error,
everything is still fine.
Stefan
--
But even if Emacs guarantees that, we still have to have some way for
emacsen-common to know that's the situation.
Emacs doesn't guarantee anything. But we know that's the situation
because it always is.
Stfean
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
But even if Emacs guarantees that, we still have to have some way for
emacsen-common to know that's the situation.
To the extent that neither aptitude nor dpkg offers a way for the user
to use something like a --force flag to ignore the problems, signaling
an error there should be limited to
i.e. if an add-on package doesn't work with a given older emacs, then
that package should add appropriate guards, and if an add-on package
This is not about a package not working with some older Emacs version.
It's about failure of *installation*, more specifically a failure which is
a pain in
Package: busybox-syslogd
Severity: normal
Dear Maintainer,
As stated in the subject, systemd and busybox-syslogd are in conflict
(via klogd, IIUC). I'm not completely uptodate on systemd, but AFAIK
it does not provide syslogd functionality, so I'd like to keep running
busybox-syslogd alongside
Package: libx11-6
Version: 2:1.6.2-1
Severity: normal
File: libX11.so
Dear Maintainer,
Ever since I added a second screen to my desktop (via a displaylink USB
graphics card), applications keep complaining about:
Xlib: extension RANDR missing on display :0.0.
Not sure where this comes from
1 - 100 of 276 matches
Mail list logo
