On Wed, 2025-03-19 at 15:36 +, Scott Ashcroft wrote:
> On Wed, 2025-03-19 at 15:25 +0000, Scott Ashcroft wrote:
> > If it works I'll send over a patch you can cherry pick.
>
> https://salsa.debian.org/sashcroft/yosys/-/commit/8b166e2bbab49d1d1b4bf211ed75203443c60c4c
&g
On Tue, 2025-03-25 at 14:02 +, Scott Ashcroft wrote:
> On Tue, 2025-03-18 at 21:52 +0000, Scott Ashcroft wrote:
> > If we can get the three fixes accepted upstream 32-bit should build
> > and
> > pass all tests.
>
> I've raised an upstream pull request:
>
On Wed, 19 Mar 2025 09:48:47 +0100 Philipp Klaus Krause
wrote:
> What is the reason to use implementation-specific builtins?
>
> The type-generic macro stdc_leading_zeros from stdbit.h (section
7.18.3
> of the ISO C23 standard) looks like it would be fine here.
Hi,
The upstream docs for buildin
On Tue, 2025-03-18 at 21:52 +, Scott Ashcroft wrote:
> If we can get the three fixes accepted upstream 32-bit should build and
> pass all tests.
I've raised an upstream pull request:
https://github.com/YosysHQ/yosys/pull/4960
Cheers,
Scott
On Wed, 2025-03-19 at 15:25 +, Scott Ashcroft wrote:
> If it works I'll send over a patch you can cherry pick.
https://salsa.debian.org/sashcroft/yosys/-/commit/8b166e2bbab49d1d1b4bf211ed75203443c60c4c
Other patches may need to be refreshed due to line number shuffles in
the Makefil
On Wed, 2025-03-19 at 16:18 +0100, Daniel Gröber wrote:
> > yosys-config has differences which look weird. Some substitution
> > thing
> > involving YOSYS_VER.
Yes. YOSYS_VER seems to have been added to the CXXFLAGS between 0.49
and 0.51.
It has quotes in it and depending on how your shell (bash v
On Tue, 2025-03-18 at 19:23 +, Scott Ashcroft wrote:
> That only leaves the cxxrtl tests failing. I don't think fixing them
> will be as straightforward.
Once I figured out what the test was trying to do it turned out to be
quite simple.
It is trying to compare the cxxrtl versi
On Tue, 2025-03-18 at 16:59 +0100, Daniel Gröber wrote:
> Actually we really ought to look into doing some more un-vendoring in yosys
> in general.
It looks like at least in yosys they apply their own patches so it
might not be that easy.
Some progress on making 32-bit work again.
I've managed t
On Tue, 2025-03-18 at 15:02 +0100, Daniel Gröber wrote:
> Last time it just needed a strategically placed (double) cast. Idk
> why this
> would have started breaking again?
https://github.com/YosysHQ/yosys/commit/2edb9397c317cb3ef3e4d29741069e0cd900eadb
"Unclear if there are any changes lost that
On Tue, 2025-03-18 at 01:32 +0100, Daniel Gröber wrote:
> We've seen FST problems due to i386 floating point weirdness before
> (rounding, 80bit>64bit conversion IIRC). Might just be something like that
> again.
Looks like you are spot on.
The i386 and amd64 versions write identical FST files.
W
On Tue, 2025-03-18 at 00:16 +0100, Daniel Gröber wrote:
> I tried quickly building 0.51 and that seems to have yet more issues:
>
> /usr/bin/ld: /tmp/cc8nRSkd.ltrans73.ltrans.o: in function
> `abc::Scl_LibertyParse(char*, int)':
> /<>/abc/src/map/scl/sclLiberty.c:563:(.text+0x41f0): undefined
>
On Mon, 2025-03-17 at 23:22 +0100, Daniel Gröber wrote:
> Let's see how this goes:
>
> Uploading to ftp-master (via ftp to ftp.upload.debian.org):
> Uploading yosys_0.49-1.dsc: done.
> Uploading yosys_0.49.orig-abc.tar.gz: done.
> Uploading yosys_0.49.orig.tar.gz: done.
> Uploading yosys_0
On Sun, 2025-03-16 at 17:34 +0100, Daniel Gröber wrote:
> Hi Steffen, Scott,
Hi.
> Nah. I'm too much of a perfectionist for that. I'd sooner switch to HTML
> output than have no docs in Debian at all (maybe we should enable those
> anyway?).
The HTML docs seem to use pip to pull in some python m
On Sat, 2025-03-15 at 19:52 +, Scott Ashcroft wrote:
> OK. I've managed to get an sbuild environment working by using the orig
> tar file from the YosysHQ github.
> The documentation issues are fixed up and I'm running what is hopefully
> the final test build now.
>
On Sat, 2025-03-15 at 16:30 +, Scott Ashcroft wrote:
> Hi,
>
> On Fri, 2025-03-14 at 21:10 +0100, Daniel Gröber wrote:
> > tl;dr: yosys packaging still has issues in the docs build. Python/sphinx
> > help wanted :-).
>
> I'd love to help but something s
Hi,
On Fri, 2025-03-14 at 21:10 +0100, Daniel Gröber wrote:
> tl;dr: yosys packaging still has issues in the docs build. Python/sphinx
> help wanted :-).
I'd love to help but something seems to have gone wrong with the
pristine-tar branch so I can't build anything.
When I try to build the packag
On Sat, 04 Jan 2025 11:03:42 +0100 Tobias Frost
wrote:
> Thanks for the information.
>
> I can reproduce it here to.
>
> Workarounds that work for me:
>
> COIN_GL_NO_CURRENT_CONTEXT_CHECK=1 freecad
>
> freecad -- -platform xcb
>
>
> This might be coin3 issue #1050302.
I see that the coi
On Mon, 2025-02-10 at 01:03 +0100, Daniel Gröber wrote:
> Hi Scott,
>
> On Wed, Feb 05, 2025 at 08:28:47PM +0000, Scott Ashcroft wrote:
> > That was much more difficult than I thought.
>
> Tell me about it! ;-)
>
> > The combination of your work and upstream had de
That was much more difficult than I thought.
The combination of your work and upstream had dealt with all the
date/time based stuff.
The tex source for the various images which get inserted had the magic:
\pdfinfoomitdate 1
\pdfsuppressptexinfo 1
\pdftrailerid{}
in them but the .tex file generate
On Tue, 2025-02-04 at 16:52 +0100, Daniel Gröber wrote:
> Hi Scott,
>
> On Tue, Feb 04, 2025 at 01:22:18PM +0000, Scott Ashcroft wrote:
> > Then out of blue there was an upload in January, still based on an
> > old
> > version.
>
> Larry reminded me to do it that
Hi,
I think I've done the work to get 0.49 packaged and it has been merged
in salsa.
Can somebody check over what I've done and do the necessary moves to
upload it?
Cheers,
Scott
On Tue, 26 Nov 2024 18:25:07 + Scott Ashcroft
wrote:
> I think the fix for this is to add:
>
> -fno-jump-tables
>
> to the OPTIMIZE flags but I don't have atmega8 to test if the
produced
> bootloader actually works.
>
>
I've now managed to find an
Control: fixed -1 6.12.5-1
Hi,
Looks like there are other users reporting that they can reproduce the
issue in the systemd bug.
The workaround of removing quiet or adding TERM=dumb to the kernel
cmdline works for me.
It is probably worth moving the Debian bug over to systemd versions
257~rc1, 257~rc2, 257~rc3 and 257.
Chee
On Tue, 2024-12-10 at 18:57 +0100, Uwe Kleine-König wrote:
> Hello,
Hi.
> On Tue, Dec 10, 2024 at 12:08:17PM +, Scott Ashcroft wrote:
> > Still happening with 6.12.3.
> > Pressing a number of keys (it doesn't need to be enter) will get
> > the
> >
Still happening with 6.12.3.
Pressing a number of keys (it doesn't need to be enter) will get the
boot moving again.
Adding any sort of debug also seems to mask the issue.
I suspect it could be a change in systemd which triggered it.
Could it something needing more entropy in /dev/random which mash
I think the fix for this is to add:
-fno-jump-tables
to the OPTIMIZE flags but I don't have atmega8 to test if the produced
bootloader actually works.
Hi,
I agree if you only read the C then the code looks fine, if a bit odd.
However, having looked at the coredump with gdb it seems the compiler
optomises the dereference out and passes back a pointer to the soon to
be invalid stack address rather than the value.
It only crashes with the stack pro
On Sat, 2022-12-03 at 14:35 +0100, Daniel Gröber wrote:
> Hi Scott,
>
> While mips64el was indeed fix it looks like now we have failures on
> armhf
> instead, which was working before the patch.
>
> I've patched the test driver to print some more debug output and it
> looks
> like berkeley-abc is
On Fri, 2022-12-02 at 14:04 +, Scott Ashcroft wrote:
> Hi,
>
> I agree if you only read the C then the code looks fine, if a bit
> odd.
> However, having looked at the coredump with gdb it seems the compiler
> optomises the dereference out and passes back a pointer to
Package: yosys
Version: 0.23-3
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack is returned to calling function
Package: yosys
Version: 0.23-3
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack
Hi,
I've done some work on why the mips64el build fails.
The issue is that the test script tests/sat/grom.ys makes yosys core in
libs/fst/fstapi.cc:fstGetUint32
Looking at the code it is clear that, when FST_DO_MISALIGNED_OPS is not
defined, an address on the stack is returned to calling function
Package: fpga-icestorm
Version: 0~20220102git3b7b199-1
Severity: normal
Dear Maintainer,
icetime seems to be looking in /usr/local/share/icebox and
/usr/bin/../share/icebox for chipdb files instead of
/usr/share/fpga-icestorm/chipdb.
icetime -d icebreaker.pcf -d up5k -P sg48 -mtr pcm.rpt pcm.as
Source: raspi3-firmware
Source-Version: 1.20181112-1
The contents of the package are:
# dpkg -L raspi3-firmware
/.
/etc
/etc/default
/etc/default/raspi3-firmware
/etc/initramfs
/etc/initramfs/post-update.d
/etc/initramfs/post-update.d/z50-raspi3-firmware
/etc/kernel
/etc/kernel/postinst.d
/etc/ke
Package: tomcat8
Version: 8.0.39-1
Severity: minor
Hi,
The default server.xml shipped with tomcat8 has an access log valve config as
follows:
So files are produced in /var/log/tomcat8 with filenames like:
localhost_access_log.2016-11-25.txt
However, the log rotation script /etc/cron.daily/t
Package: network-manager
Version: 1.2.0-1
Severity: normal
There seems to be some sort of problem where dhclient gets an IPv6 address but
it gets expires almost straight away.
Then since dhclient isn't running any more it doesn't get renewed.
Debug log from network manager looks like this:
May
> Could you boot a working kernel with memblock=debug on the kernel
I'm not seeing any 'memblock: Could not reserve boot range' lines.
See attached.
Tried the patch anyway and it didn't work.
Cheers,
Scott[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys
The patch makes no difference.
Is there anything else I can do to help figure this out?
Cheers,
Scott
I'm still seeing the same failure in efi_call with 4.4.4-1 and 4.5-rc4
and 4.5-rc7 from experimental on an HP x360.
It has the INSYDE Corp implementation of EFI which seems to be a common
factor.
I'll try build the kernel with the patch suggested and test that.
Cheers,
Scott
On Fri, 2015-07-10 at 19:09 +0200, Andreas Beckmann wrote:
> Control: tag -1 moreinfo
>
> Hi Scott,
>
> On Tue, 9 Oct 2012 10:57:09 +0100 (BST) Scott Ashcroft
> wrote:
> > I've got serveral milters when crash when under high load.
> > The problem seems to be
Hi,
This isn't a bug in the dhcp client but a misconfiguration of your dhcp server.
The 'DHCP Client Behavior' section of RFC3442 says, in part:
"If the DHCP server returns both a Classless Static Routes option and a Router
option, the DHCP client MUST ignore the Router option."
So you jus
Hi,
I can't reproduce this and I run a dhcp server with DHCP_INTERFACES=""
Is there anything in /var/log/daemon.log which shows why dhcpd didn't start?
Cheers,
Scott
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
Hi,
I think the problem is that dhcp client is being killed off by
/etc/init.d/sendsigs script.
This means that it is dead by the time the nfs unmount script runs and that's
why there is no network.
I suspect that it should be making a symlink in /run/sendsigs.omit.d like
rpcbind, syslog and
Package: libmilter1.0.1
Version: 8.14.4-2.1
Severity: normal
Hi,
I've got serveral milters when crash when under high load.
The problem seems to be that a signal is caught in poll but the handler doesn't
do the right thing.
I think the problem is that the signal shouldn't fire at all.
From the
I don't believe that this a bug in freerdp but only in remmina.
If you run xfreerdp with the cliprdr plugin:
xfreerdp --plugin cliprdr
then the clipboard works correctly.
remmina appears to be loading that plugin:
grep cliprdr /proc/8389/maps
7fae695ef000-7fae695f2000 r-xp 08:02 1440
Felix Zielcke <[EMAIL PROTECTED]> wrote:
>
> Am Sonntag, den 09.11.2008, 19:11 +0000 schrieb Scott Ashcroft:
> > Package: grub-common
> > Version: 1.96+20080724-11
>> Severity: important
> >
> >
> > grub-probe misdetects the root fs
Package: grub-common
Version: 1.96+20080724-11
Severity: important
grub-probe misdetects the root fs of one of my PCs (works fine on all others).
lisa:/# grub-probe --target=fs /
fat
lisa:/# sfdisk -l /dev/sda
Disk /dev/sda: 19452 cylinders, 255 heads, 63 sectors/track
Units = cylinders of 822
49 matches
Mail list logo
