Bug#995467: Salvaging status

Can I pass the baton of mlton package ownership off to someone? I've been intending to some day come back to working on this, but the reality is, I probably never will. I'd be happy to answer questions about how to get things to work, if that is helpful. You need someone who either is currently

[tip: irq/core] irqchip/sifive-plic: Remove incorrect requirement about number of irq contexts

The following commit has been merged into the irq/core branch of tip: Commit-ID: 82f2202ddc97490994fad0dbfec04a014fa5163d Gitweb: https://git.kernel.org/tip/82f2202ddc97490994fad0dbfec04a014fa5163d Author:Wesley W. Terpstra AuthorDate:Tue, 12 May 2020 10:26:36 -07:00

Bug#904475: mlton: build-depends on the version of itself that is going to be built

On Tue, Jul 24, 2018 at 9:01 AM, Andreas Beckmann wrote: > Source: mlton > Version: 20180207-1 > Severity: serious > Justification: fails to build from source (but built successfully in the > past) > > now you got the package deadlocked w.r.t. their build-depends > Nah. This is a normal

Bug#904475: mlton: build-depends on the version of itself that is going to be built

On Tue, Jul 24, 2018 at 9:01 AM, Andreas Beckmann wrote: > Source: mlton > Version: 20180207-1 > Severity: serious > Justification: fails to build from source (but built successfully in the > past) > > now you got the package deadlocked w.r.t. their build-depends > Nah. This is a normal

Accepted mlton 20180207-1 (source amd64) into unstable

-powerpc-linux-gnu mlton-runtime-powerpc64le-linux-gnu mlton-runtime-riscv64-linux-gnu mlton-runtime-s390x-linux-gnu mlton-runtime-sparc-linux-gnu Architecture: source amd64 Version: 20180207-1 Distribution: sid Urgency: low Maintainer: Wesley W. Terpstra Changed-By: Wesley W. Terpstra

Bug#890791: Proposed updates?

Good evening, I was wondering where I can find the proposed-updates version of dpkg with the riscv64 architecture line added to /usr/share/dpkg/cputable. I thought I'd be able to find it on < https://release.debian.org/proposed-updates/stable.html>, but it's not listed, so I must be looking in

Bug#890791: Proposed updates?

Good evening, I was wondering where I can find the proposed-updates version of dpkg with the riscv64 architecture line added to /usr/share/dpkg/cputable. I thought I'd be able to find it on < https://release.debian.org/proposed-updates/stable.html>, but it's not listed, so I must be looking in

[PATCH 3/3] pwm-sifive: add a driver for SiFive SoC PWM

SiFive SoCs can contain one or more PWM IP blocks. This adds a driver for them. Tested on the HiFive Unleashed. Signed-off-by: Wesley W. Terpstra <wes...@terpstra.ca> --- drivers/pwm/Kconfig | 11 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c

[PATCH 3/3] pwm-sifive: add a driver for SiFive SoC PWM

SiFive SoCs can contain one or more PWM IP blocks. This adds a driver for them. Tested on the HiFive Unleashed. Signed-off-by: Wesley W. Terpstra --- drivers/pwm/Kconfig | 11 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-sifive.c | 259

[PATCH 0/3] SiFive SoC PWM driver

, in Documentation/devicetree/bindings Wesley W. Terpstra (3): dt-bindings: added new pwm-sifive driver documentation dt-bindings: Add "sifive" vendor prefix pwm-sifive: add a driver for SiFive SoC PWM .../devicetree/bindings/pwm/pwm-sifive.txt | 28 +++ .../devicetre

[PATCH 0/3] SiFive SoC PWM driver

, in Documentation/devicetree/bindings Wesley W. Terpstra (3): dt-bindings: added new pwm-sifive driver documentation dt-bindings: Add "sifive" vendor prefix pwm-sifive: add a driver for SiFive SoC PWM .../devicetree/bindings/pwm/pwm-sifive.txt | 28 +++ .../devicetre

[PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation

Document new PWM device tree bindings for SiFive SoCs. Signed-off-by: Wesley W. Terpstra <wes...@sifive.com> --- .../devicetree/bindings/pwm/pwm-sifive.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/p

[PATCH 1/3] dt-bindings: added new pwm-sifive driver documentation

Document new PWM device tree bindings for SiFive SoCs. Signed-off-by: Wesley W. Terpstra --- .../devicetree/bindings/pwm/pwm-sifive.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt diff --git

[PATCH 2/3] dt-bindings: Add "sifive" vendor prefix

This adds a vendor prefix "sifive" for SiFive, Inc. We make chips. Signed-off-by: Wesley W. Terpstra <wes...@sifive.com> --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor

[PATCH 2/3] dt-bindings: Add "sifive" vendor prefix

This adds a vendor prefix "sifive" for SiFive, Inc. We make chips. Signed-off-by: Wesley W. Terpstra --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/

Bug#890791: Progress?

Has there been any progress on this issue? I maintain a package with an explicit Architecture list and I wanted to port it to my new riscv64 system, but I can't upload the new source package to unstable because it mentions riscv64 in the control file. It's quite frustrating that backporting this

Bug#890791: Progress?

Has there been any progress on this issue? I maintain a package with an explicit Architecture list and I wanted to port it to my new riscv64 system, but I can't upload the new source package to unstable because it mentions riscv64 in the control file. It's quite frustrating that backporting this

Bug#857220: mlton-tools: broken symlink: /usr/share/doc/mlton-tools/README -> doc/README

Thanks for the report. I probably won't make a new upload to fix this issue alone, but will be sure to fix it with the next upload.

Accepted mlton 20130715-3 (source) into unstable

-powerpc-linux-gnu mlton-runtime-powerpc64le-linux-gnu mlton-runtime-s390x-linux-gnu mlton-runtime-sparc-linux-gnu Architecture: source Version: 20130715-3 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra <terps...@debian.org> Changed-By: Wesley W. Terpstra <terps...@d

Accepted mlton 20130715-2 (source all kfreebsd-amd64) into unstable, unstable

-powerpc-linux-gnu mlton-runtime-powerpc64le-linux-gnu mlton-runtime-s390x-linux-gnu mlton-runtime-sparc-linux-gnu Architecture: source all kfreebsd-amd64 Version: 20130715-2 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra <terps...@debian.org> Changed-By: Wesley W. Te

Accepted mlton 20130715-1 (source all amd64) into unstable

mlton-runtime-s390-linux-gnu mlton-runtime-sparc-linux-gnu Architecture: source all amd64 Version: 20130715-1 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra <terps...@debian.org> Changed-By: Wesley W. Terpstra <terps...@debian.org> Description: mlton - Optimiz

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

On Mon, Apr 4, 2016 at 8:42 PM, Alexander Duyck wrote: > It is always possible that the SFP+ cages on the device may not dissipate > enough heat for a given SFP+ module If an SFP is capable of melting itself or other devices, that is the fault of the SFP, not Intel's

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

On Mon, Apr 4, 2016 at 7:28 PM, Alexander Duyck wrote: >> DO NOT FOLLOW THIS GUIDE UNLESS YOU DON'T FEAR BRICKING YOUR CARD! > > Actually possible repercussions are far worse than bricking your card. > You could potentially burn up the entire system if you mess with an

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

On Mon, Apr 4, 2016 at 7:09 AM, Oleg A. Arkhangelsky wrote: > Sourceforge eat mail attachments. Put your program somewhere else. Ok. Thanks for pointing this out! I've put a slightly improved version up at:

Re: [E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

Sorry for the earlier message! My hand hit the send button before I'd finished writing the email. I had a bit more time this weekend, and I managed to unlock my X710-DA4. It now accepts any SFP+. I tried four different models of 10GBASE-LR transceivers in the card, and they all seemed to work

[E1000-devel] HOWTO: unlock your Intel XL710 / X710 for use with any SFP+

I had a bit more time this weekend, and I managed to unlock my X710-DA4. It now accepts any SFP+. I tried four different models of 10GBASE-LR transceivers in the card, and they all seemed to work just fine. Admittedly, I only tested that they could hit 1.1GiB/s TCP flows for a few minutes before

Re: [E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

Thank you for your feedback, > Also be aware that a large chunk of the NVM image is signed and won't > work if the signature and/or checksum is found invalid. I don't remember > if the Qualified Module bits are in the signed portion, but I suspect they > are. The data sheet (Section 6) says

Re: [E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

to the different modules. The data sheet I have does not discuss this. Does someone have a more up-to-date data sheet and/or knowledge of how the module pointers and NVM address and module relate? And/or the source code to nvmupdate64e which certainly is doing this correctly? Thanks for any

[E1000-devel] i40e: source for nvmupdate64e? (to clear module qualification)

Hi! I have an Intel X710-DA4 and want to use it with a few different SFPs. Unfortunately, out-of-the-box this seems to be disabled. >From poking around, it seems that the x710 firmware rejects SFPs not listed in the NVM qualified database whenever the "Enable Module Qualification" bit is set (see

Bug#791928: Please support ARM64 (#error Unknown CPU architecture)

Porting mlton is easy. I ported it to most of the debian archs already. All i need is a debian porterbox and buildd when i prepare a new upload. On Jul 9, 2015 6:00 PM, Martin Michlmayr t...@hp.com wrote: Package: st Version: 1.9-3.1 Severity: wishlist User: debian-...@lists.debian.org

Re: [rust-dev] Newcomer to Rust: my experience

think you'd better post it on http://users.rust-lang.org/, since it is the main place for Rust discussions now. The mailing list is almost dead. -- Oleg On Mon, Apr 6, 2015 at 4:23 PM Wesley W. Terpstra wes...@terpstra.ca wrote: Good afternoon and happy easter, I am a newcomer to Rust

[rust-dev] Newcomer to Rust: my experience

Good afternoon and happy easter, I am a newcomer to Rust and recently finished working through your tutorial. Before I get too much further into reading the standard library, I wanted to share my experience as a complete Rust newbie starting out only with your documentation, before I forget it. I

Bug#780981: avahi-daemon: Avahi-daemon loses name when used with dynamic IPv6

Package: avahi-daemon Version: 0.6.31-4+b2 Severity: important Dear Maintainer, FYI, This is clearly an upstream bug, but I could not figure out the upstream BTS. Since this affects jessie, I figure it also important to mention here. Please forward this bug upstream. So, here's the problem.

[Pkg-utopia-maintainers] Bug#780981: avahi-daemon: Avahi-daemon loses name when used with dynamic IPv6

Package: avahi-daemon Version: 0.6.31-4+b2 Severity: important Dear Maintainer, FYI, This is clearly an upstream bug, but I could not figure out the upstream BTS. Since this affects jessie, I figure it also important to mention here. Please forward this bug upstream. So, here's the problem.

Bug#685878: Netatalk 3?

Hi, I've been using a self-built netatalk3 in debian for quite some time. I assume there is a good reason that debian/sid still has 2.2.2? If it's just manpower, I'd be happy to help with packaging. It would be a real pity if jessie ships with a 3-year-old netatalk.

Bug#685878: [Pkg-netatalk-devel] Netatalk 3?

On Mon, Nov 3, 2014 at 8:29 PM, Jonas Smedegaard d...@jones.dk wrote: Hi Wesley, Hey Jonas. Long time no see! If you are only intrested in helping with Netatalk 3, then that's fine too. Well, I personally need netatalk = 3. Netatalk 2 doesn't do time machine properly. But I highly doubt

Re: Best way to carry on 2-input architecture?

On Fri, Aug 22, 2014 at 11:46 AM, Wesley W. Terpstra wes...@terpstra.ca wrote: H = (x - L) mod (B-1) So let me get this straight. Your plan is to compute x=a*b mod (B-1). In other words, you sum 64 columns of 64-rows in a square shape instead of the usual parallelogram. Then you throw

Re: Best way to carry on 2-input architecture?

On Fri, Aug 22, 2014 at 2:06 PM, Niels Möller ni...@lysator.liu.se wrote: But a 64-bit mul is usually not single cycle? Of course not. I'm not sure what you're driving at here. If mullo and mulhi both have the same clock and are both 3 cycles deep, it does not matter if one has slightly lower

Re: Best way to carry on 2-input architecture?

On Wed, Aug 20, 2014 at 10:59 AM, Niels Möller ni...@lysator.liu.se wrote: I've been thinking that if you want the full two-word result of a multiply, and compute each part separately using mulhi and mullo, the mulhi operation will have to compute the full product anyway, discarding the low

Re: Best way to carry on 2-input architecture?

On Wed, Aug 20, 2014 at 10:59 AM, Niels Möller ni...@lysator.liu.se wrote: One could build it out of smaller blocks, say we have combinatorial 8x8 multipliers. We then need 64 of those, in sequence or parallel, and a bunch of adders. Or we could use Karatsuba, to do a 64x64 using 27 8x8

Re: Best way to carry on 2-input architecture?

On Sun, Aug 17, 2014 at 10:00 PM, Niels Möller ni...@lysator.liu.se wrote: t...@gmplib.org (Torbjörn Granlund) writes: My work is available here: https://gmplib.org/~tege/fisa.pdf Thank you for the link. And mine at http://www.lysator.liu.se/~nisse/misc/instr16.pdf (a toy project, trying to

Re: Best way to carry on 2-input architecture?

On Mon, Aug 18, 2014 at 9:01 AM, Niels Möller ni...@lysator.liu.se wrote: I don't think it has to be that bad. First, the prefix flag and register should be saved and restored on irq, so there should be no problem with irq:s or page faults and the like in the middle of an instruction. Yes,

Re: Best way to carry on 2-input architecture?

So, yeah, we're drifting pretty far off-topic now. If you have follow-up questions that you think aren't interesting for gmp-devel, just send them to me privately. On Mon, Aug 18, 2014 at 2:35 PM, Niels Möller ni...@lysator.liu.se wrote: I think the decoder could implement the prefix

Best way to carry on 2-input architecture?

Good evening, As a hobby project I've been building an out-of-order superscalar CPU for use in FPGAs. Everything has been going pretty smoothly, but I'd like to be able to support gmplib efficiently on it. To keep the issue stage small+fast, instructions on this machine can only accept two

Bug#725884: Me too!

Just wanted to mention this bug affects me as well. I have the same disks (WD30EZRX). As I found this bug report via google, it's not surprising we have the same hard disk, however. I can spin the disk down with 'hdparm -y /dev/sdd' and it stays spun down for hours. However, the disk will never

Using bcache to save power -- safe?

Good afternoon! My question: Can I leave writeback_running=0, or will it hurt my data? Background: I've started using bcache on my NAS array and must say it is working out quite well. My goals were energy/noise savings and performance. These appear to be met with my current configuration.

Bug#707410: mlton: FTBFS: gc/int-inf.c:180:43: error: unknown type name '__gmp_const'

Yes, I also have a patch, but the next MLton is due out shortly and it includes the patch. I am just waiting for the release. On Tue, Jun 25, 2013 at 6:53 PM, Sebastian Ramacher sramac...@debian.orgwrote: Control: tags -1 + patch upstream fixed-upstream Control: forwarded -1

Bug#707410: mlton: FTBFS: gc/int-inf.c:180:43: error: unknown type name '__gmp_const'

Yes, I also have a patch, but the next MLton is due out shortly and it includes the patch. I am just waiting for the release. On Tue, Jun 25, 2013 at 6:53 PM, Sebastian Ramacher sramac...@debian.orgwrote: Control: tags -1 + patch upstream fixed-upstream Control: forwarded -1

[PATCH] usb-serial: add support for USB Wishbone-serial adapters

the Etherbone protocol. A userspace library is required to speak the protocol made available by this driver as ttyUSBx. Signed-off-by: Wesley W. Terpstra w.terps...@gsi.de --- drivers/usb/serial/Kconfig | 17 ++ drivers/usb/serial/Makefile |1 + drivers/usb/serial/wishbone

Re: [PATCH] usb-serial: add support for USB Wishbone-serial adapters

On Thu, 2013-04-11 at 06:45 -0700, Greg KH wrote: I only have one very minor question about the code: +++ b/drivers/usb/serial/wishbone-serial.c @@ -0,0 +1,95 @@ +/* + * USB Wishbone-Serial adapter driver + * + * Copyright (C) 2013 Wesley W. Terpstra w.terps...@gsi.de

Re: [PATCH] usb-serial: add support for USB Wishbone-serial adapters

On Thu, 2013-04-11 at 08:15 -0700, Greg KH wrote: Fair enough, although this driver would probably be the least of our worries if that were to happen :) Of course. Documenation/stable_api_nonsense.txt Tactfully named. :) Is there a document that describes how to track the progress a patch

USB-Wishbone bridge adapter

(usb_wb_device); } MODULE_AUTHOR(Wesley W. Terpstra w.terps...@gsi.de); MODULE_DESCRIPTION(Wishbone-USB adapter); MODULE_LICENSE(GPL); module_init(usb_wb_init); module_exit(usb_wb_exit);

Re: USB-Wishbone bridge adapter

On Wed, 2013-04-10 at 19:01 +0200, Wesley W. Terpstra wrote: I've attached the output of lsusb -v ... and of course attached the output of an older version of the device. The capabilities should read: CDC ACM: bmCapabilities 0x02 line coding and serial state

Re: USB-Wishbone bridge adapter

On Wed, 2013-04-10 at 10:08 -0700, Greg KH wrote: On Wed, Apr 10, 2013 at 07:01:40PM +0200, Wesley W. Terpstra wrote: Greg, I've attached a small Linux driver which recognizes and the USB-Wishbone functionality of the device. It just adds two vendor messages to signal to the FPGA

Re: Piggy-backing new hardware using old usb-serial

On Thu, 2013-03-28 at 09:39 -0500, Dan Williams wrote: Greg's right, there's no reason not to use cdc-acm if you want to do that, since not all cdc-acm devices are modems. If you get a USBIF vendor ID, then I'll happily add your device to the ModemManager probing blacklist too. Yes, the

Piggy-backing new hardware using old usb-serial

Good evening, We are developing a custom piece of hardware that provides the equivalent of two serial console interfaces. They do not speak the AT command set. One port provides an interactive console to the user for configuration purposes (via minicom/etc). The other speaks a proprietary

Re: Piggy-backing new hardware using old usb-serial

On Wed, 2013-03-27 at 13:06 -0700, Greg KH wrote: Our current prototypes borrow the Sierra VID And the USB-IF might revoke your vendor id, if they find you shipping a device with a different vendor id than the one you have been assigned. One of the reasons we borrowed that VID is that we do

buildd.debian.org: Mipsel blacklist for package MLton

Package: buildd.debian.org Severity: normal Good evening! The package 'MLton' needs a minimum of 1GB physical memory to compile. Otherwise it will thrash in swap until killed. The mips buildd recently tried to build this package on phrixos which only has 512MB. Naturally, this failed [1]. Please

Bug#635004: buildd.debian.org: Mipsel blacklist for package MLton

Package: buildd.debian.org Severity: normal Good evening! The package 'MLton' needs a minimum of 1GB physical memory to compile. Otherwise it will thrash in swap until killed. The mips buildd recently tried to build this package on phrixos which only has 512MB. Naturally, this failed [1]. Please

Accepted mlton 20100608-5 (source all amd64)

mlton-runtime-s390-linux-gnu mlton-runtime-sparc-linux-gnu Architecture: source all amd64 Version: 20100608-5 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org Description: mlton

Re: [Qemu-devel] qemu-user[armel/mips] and debian-rootfs

2011/7/11 Riku Voipio riku.voi...@iki.fi: On Mon, Jul 11, 2011 at 11:10:50AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Thanks Riku! This bug has already been solved by Wesley Terpstra: http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg00313.html Ok, I missed these patches.

[Qemu-devel] Best qemu ARM board supporting 1G+ ?

Greetings. I have a arm/versatileab running debian/sid, but this only has access to 256MB of main memory. For my current project I need a minimum of 1GB. I know that the realview-pbx-a9 can do this, but am unsure how well its supported. 1. Which qemu ARM boards support = 1GB of memory? 2. Which

[Qemu-devel] [PATCH 1/6] mips: sigaltstack args

The syscall sigaltstack takes two parameters, not zero. This patch should have no impact as only values above 4 influence the runtime behaviour. Nevertheless, it is wrong. Signed-off-by: Wesley W. Terpstra terps...@debian.org --- diff --git a/linux-user/main.c b/linux-user/main.c index 289054b

[Qemu-devel] [PATCH 3/6] mips: null pointer deref should segfault

Dereferencing a null pointer causes an exception 0xC (EXCP_AdEL) instead of EXCP_TLBL. This should also trigger a segfault. Signed-off-by: Wesley W. Terpstra terps...@debian.org --- diff --git a/linux-user/main.c b/linux-user/main.c index 289054b..26ebc73 100644 --- a/linux-user/main.c +++ b

[Qemu-devel] [PATCH 2/6] mips: missing syscall returns wrong errno

Return -TARGET_ENOSYS instead of -ENOSYS from linux-user/main.c * Caused strange 'Level 2 synchronization messages' instead of correctly reporting the syscall was missing. * Made glibc simply fail instead of using older syscalls Signed-off-by: Wesley W. Terpstra terps...@debian.org

[Qemu-devel] [PATCH 6/6] mips: eabi syscall support for 64-bit args

mips uses the eabi calling convention. For 64-bit values this means some registers are skipped. This patch replicates the behaviour of arm/eabi for mips targets. This affects ftruncate64, creating insane sized fails (or just failing). Signed-off-by: Wesley W. Terpstra terps...@debian.org

[Qemu-devel] [PATCH 4/6] mips: rlimit incorrectly converts values

dies Signed-off-by: Wesley W. Terpstra terps...@debian.org --- diff --git a/linux-user/syscall.c b/linux-user/syscall.c index fed7a8f..0b0a3d0 100644 --- a/linux-user/syscall.c +++ b/linux-user/syscall.c @@ -919,18 +919,30 @@ static inline abi_long host_to_target_rusage(abi_ulong target_addr

[Qemu-devel] [PATCH 5/6] mips: rlimit codes are not the same

The codes for get/setrlimit differ between linux target platforms. This patch adds conversion. This is important else programs (rsyslog, python, ...) can go into a near infinite loop trying to close all the file descriptors from 0 to -1. Signed-off-by: Wesley W. Terpstra terps...@debian.org

[Qemu-devel] PATCH: fix qemu-mips[el]-static to work with debian squeeze/sid chroot

I also recently tried to get a mipsel debian/sid chroot running under my amd64/squeeze system. As posted by Lisandro earlier this month, it didn't work. ;-) There are several problems, the most glaring of which the attached patch fixes. I'll break down the changes: 1. Return -TARGET_ENOSYS

Re: [Milkymist-devel] MMU

On 23/04/11 12:55 PM, Sebastien Bourdeauducq wrote: b) Use a simple cache with cache associativity * page size = cache size. Advantages: simple hardware, and solves above problems. Half the point of the LM32 is the sweet-spot in speed/size that it hits. This approach to an MMU lives at a

Re: [Milkymist-devel] MMU

Although I've already mentioned there are absolutely no problems with a VIPT mmu/cache design under the cache-size assumption Sebastien worked with, there is *also* no problem with exceeding this cache-size restriction for an operating system like linux. I'll explain why below. On 25/04/11

Either as or ld produce a bad jump on mips eabi

Good evening, on and off for years, I've been bitten by a miscompilation of 'goto' on the mips target. I finally isolated it into a single test-case that I can report. I believe this bug to be at least 6 years old and it is still present in version 2.18.1~cvs20080103-7 (as used in debian/sid).

Accepted mlton 20100608-4 (source all i386)

-runtime-sparc-linux-gnu Architecture: source all i386 Version: 20100608-4 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org Description: mlton - Optimizing compiler for Standard ML

Re: mlton any-all package transition breakage

On Fri, Apr 1, 2011 at 9:58 PM, Peter Palfrader wea...@debian.org wrote: all the other chroots are now fucked because we did as you asked, and for some reason it wants to bring in mlton-doc The problem there is you're trying to install and/or upgrade the sid one, not the squeeze one. I

Re: mlton any-all package transition breakage

On Fri, Apr 1, 2011 at 10:47 PM, Peter Palfrader wea...@debian.org wrote: The problem there is you're trying to install and/or upgrade the sid one, not the squeeze one. No, the squeeze package installed cleanly. now apt-get update upgrade breaks. That means the package is buggy. Yes,

mlton any-all package transition breakage

Good afternoon. I am the maintainer for the Standard ML 97 (SML) compiler mlton. This compiler is itself written in SML and is self-hosting. Thus, it needs an older version of the compiler in order to bootstrap itself. Further complicating things, the build needs in the ballpark of 1-2GB of

Re: new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx k...@roeckx.be wrote: On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote: If I may ask, for what purpose do the buildds have a special list of packages above and beyond those in unstable? So that in case various packages have

new buildd dependency resolution breaks self depends?

I've read that there was a recent change made to the buildd resolution with regards to ensuring that consistent package versions are used on the builds [0]. Is it possible that this changed also messed up self-dependency resolution? My package, mlton, has a versioned dependency on itself for

Re: new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 5:52 PM, Julien Cristau jcris...@debian.org wrote: As far as I can tell the problem is that you switched the mlton binary package to 'Architecture: all'. Which means it's available on all architectures already in the new version, even though it's not installable.

Re: new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 6:42 PM, Kurt Roeckx k...@roeckx.be wrote: As long as the Packages file for the buildds mentions this arch all package, no buildd can build it, because it only considers installing the latest version. But it should get removed from that file after 24 or 32 hours or

Re: new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 7:27 PM, Kurt Roeckx k...@roeckx.be wrote: Note that in unstable you don't see the arch arch all version until the arch any version is also available. Or you would see the old arch all version until the new arch any version is available. That's great! My thanks to

Re: [buildd-tools-devel] new buildd dependency resolution breaks self depends?

On Tue, Mar 29, 2011 at 7:10 PM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: Does mlton-basis depend on mlton-runtime or mlton-compiler to build? If the answer is yes, then most likely these should not be three seperate source packages. It's all one source package. I split it up

Accepted mlton 20100608-3 (source all i386)

-runtime-sparc-linux-gnu Architecture: source all i386 Version: 20100608-3 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org Description: mlton - Optimizing compiler for Standard ML

Bug#619162: RM: mlton-cross -- ROM; Bad idea

Package: ftp.debian.org Severity: normal I had tried to support cross-compiling Standard ML with this package, but it needed to extract files from the main mlton package to achieve this effect, much like the evil ia32libs package. Since then, I've built a better solution that should work with

Re: [Milkymist-devel] LM32 patch licensing

I've CC'd this to the list so my advocacy gets archived. ;) On 09/03/11 12:34 AM, Michael Walle wrote: Mh, xilinx has the bscan cell, which basically has a TDI and TDO and that gets connected to the real JTAG pins if you select the proper instruction (USER1, USER2, etc). The 'internal' JTAG TAP

Re: [Milkymist-devel] Some tweaks to the LM32 used at GSI

On 07/03/11 04:21 PM, Sebastien Bourdeauducq wrote: Yes, but in some cases, a synthesizer that supports retiming Ok, I was under the impression the FPGA synthesis tools didn't do this and it was more the domain of ASIC tools. Quartus clearly doesn't support it (since I see an improvement by

Re: [Milkymist-devel] Some tweaks to the LM32 used at GSI

On 28/02/11 01:54 PM, Sebastien Bourdeauducq wrote: Michael, what do you think of the JTAG modifications below (I have not touched this part and I quite don't know how it works) ? Ok, I've improved on that last patch for the JTAG interface. I found (while getting openocd working) that my

[Milkymist-devel] Some tweaks to the LM32 used at GSI

The changes in this patch: 1. add a JTAG capture pin = allows removing sensitivity to reg_update which caused clocking problems making JTAG unstable 2. support register file backed by ram blocks = saves quite some area and speed on altera ... be sure to enable it using `define

Re: Arm blacklist for package MLton

On Wed, Nov 10, 2010 at 1:02 AM, Hector Oron hector.o...@gmail.com wrote: AFAIK blacklisting per buildd is not available[1]. I've had the same problem on other architectures and had it solved there this way, so I assume/hope arm is no different. In any case, this email might be best placed as

Bug#603002: buildd.debian.org: Arm blacklist for package MLton

Package: buildd.debian.org Severity: normal Good afternoon. To compile my package, MLton, a buildd needs 1GB of physical memory (or else it will thrash swap so badly the build fails). Until recently, none of the arm buildd's met this requirement and thus I had to use qemu to build the binary

Arm blacklist for package MLton

Good afternoon. To compile my package, MLton, a buildd needs 1GB of physical memory (or else it will thrash swap so badly the build fails). Until recently, none of the arm buildd's met this requirement and thus I had to use qemu to build the binary package for this platform. Now that there are

Bug#591174:

Where in the policy is it forbidden to download from the Internet? I actually looked for this before I packaged it: terps...@orange:/usr/share/doc/debian-policy$ zgrep -i internet policy.txt.gz MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) is a

Bug#591174:

Where in the policy is it forbidden to download from the Internet? I actually looked for this before I packaged it: terps...@orange:/usr/share/doc/debian-policy$ zgrep -i internet policy.txt.gz MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) is a

Accepted mlton-cross 20100608-2 (source all)

Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W. Terpstra (Debian) terps...@debian.org Description: mlton-target-alpha-linux-gnu - Cross-compiler support files for MLton on alpha-linux-gnu mlton-target-amd64-mingw32msvc - Cross-compiler support files for MLton

Accepted mlton 20100608-2 (source armel)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 14 Jun 2010 18:28:58 +0200 Source: mlton Binary: mlton Architecture: source armel Version: 20100608-2 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W. Terpstra

Accepted mlton 20100608-1 (source amd64)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 11 Jun 2010 16:11:59 +0200 Source: mlton Binary: mlton Architecture: source amd64 Version: 20100608-1 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W. Terpstra

Bug#552314: gcc 4.3.4 even worse

The 'use -fPIC' hack I've been using to avoid this problem doesn't help with the newest gcc in sid. https://buildd.debian.org/fetch.cgi?pkg=mltonarch=mipsver=20100504~svn-r7459stamp=1273006902file=logas=raw gcc -std=gnu99 -c -I/usr/lib/mlton/targets/self/include \

Bug#552314: gcc 4.3.4 even worse

The 'use -fPIC' hack I've been using to avoid this problem doesn't help with the newest gcc in sid. https://buildd.debian.org/fetch.cgi?pkg=mltonarch=mipsver=20100504~svn-r7459stamp=1273006902file=logas=raw gcc -std=gnu99 -c -I/usr/lib/mlton/targets/self/include \

Accepted mlton 20100504~svn-r7459 (source i386)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 04 May 2010 19:26:59 +0200 Source: mlton Binary: mlton Architecture: source i386 Version: 20100504~svn-r7459 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W

Accepted bidentd 1.1.4-1 (source i386)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 29 Apr 2010 16:50:54 +0200 Source: bidentd Binary: bidentd Architecture: source i386 Version: 1.1.4-1 Distribution: unstable Urgency: low Maintainer: Wesley W. Terpstra (Debian) terps...@debian.org Changed-By: Wesley W. Terpstra

  1   2   3   4   5   >