Bug#1016963: Please test u-boot for sheevaplug mx6cuboxi

Sadly, my sheevaplug was not revivable. I have a couple of OpenRD boxes and a couple of CUBox-i boxes I can test for you, as well as a RaspberryPi-4B and a couple of Orange-Pi boxes that can also be tested. I'll send results as I get to them. BTW, are there directions for installing and

Bug#1016963: Help with testing u-boot!

Here's another Cubox-i. This one's running Bookworm. shows a surprising number of u-boot- packages installed, ( = exynos, imx, omap, sunxi) as well as plain "u-boot". All of them are version 2022.04+dfsg-2+b1. Rebooting while watching the serial console output says "U-Boot SPL

Bug#1016963: Help with testing u-boot!

A Cubox-i running Debian bullseye (11.6). According to It has "u-boot-tools" (version 2021.01+dfsg-5) installed, but none of the u-boot- packages installed. If I reboot it and watch the serial console, I see it showing "U-boot 2021.01-dfsg-5" so that version must have gotten into the

Bug#1016963: Help with testing u-boot!

Raspberry Pi 4B (8GB) running bullseye, but does not seem to have any version of u-boot installed. Weird? Running tells me that the following (among lots of others) versions are available. Should I install one of them and see what happens? Package u-boot-rpi: p 2021.01+dfsg-5 stable 500

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

On Sun, 14 Mar 2021 00:39:40 -0800 Rick Thomas wrote: > Package: haveged > Version: 1.9.14-1 > Severity: normal > > Dear Maintainer, > > I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to > Bullseye and now haveged crashes. > I tri

Bug#934072: OpenRD images are gone

Short story: Works a treat! Longer story: Details will have to wait (it's 3AM right now) but to keep it short -- I put the two uI* files (ignored the .dtb file) onto an ext2 partition of a USB stick. Followed the instructions on Martin's page, and successfully installed back to the

Bug#934072: OpenRD images are gone

On Wed, Jun 22, 2022, at 7:27 AM, Cyril Brulebois wrote: >> (If it builds, can you upload the images somewhere so Rick can test >> them?) > > Sure, that was the plan all along. > > https://people.debian.org/~kibi/openrd4bullseye/ has the tarball after a > full debian-installer build (it'll stay

Bug#934072: OpenRD images are gone

/boot/arm/armel-kirkwood-u-boot-image-config >> is obviously fine) >> >> I don't have an OpenRD anymore but I can probably find someone if >> testing is required. > > I became aware recently that this was never fixed. Rick Thomas has > two OpenRD (Ultimate and Client

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

> Pushed a fix to git: > > https://salsa.debian.org/kernel-team/linux/-/commit/f952b94621847732b3ed96a74babb89b6a1862f6 Wow! Thanks! At least I now know I'm not crazy... Any idea how long it will be before the fix is in something I can download and install with? Enjoy! Rick

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

On Wed, Jun 9, 2021, at 3:15 AM, John Paul Adrian Glaubitz wrote: > Control: severity -1 normal > > Hello Rick! > > On 6/9/21 11:15 AM, Rick Thomas wrote: > > Package: grub-common > > Version: 2.04-18 > > Severity: grave > > File: /usr/sbin/grub-mkco

Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

Package: grub-common Version: 2.04-18 Severity: grave File: /usr/sbin/grub-mkconfig Justification: renders package unusable X-Debbugs-Cc: debian-powe...@lists.debian.org, glaub...@physik.fu-berlin.de, rbtho...@pobox.com This is what happens when I attempt to do "aptitude full-upgrade" on my

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

On Tue, Jun 1, 2021, at 11:06 PM, Vagrant Cascadian wrote: > On 2021-06-01, Rick Thomas wrote: > > Is there any estimate of when the assumed fix (linux/5.10.40-1) will > > show up in the installer at [1] ? I'd love to test it! > ... > > [1] https://d-i.debian.org/daily-im

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

Hi! Is there any estimate of when the assumed fix (linux/5.10.40-1) will show up in the installer at [1] ? I'd love to test it! Failing that, is there some other place I can get an installer SDcard image with that fix? Thanks! Rick [1]

Bug#982270: linux: [armhf] several imx6 systems unable to detect ethernet

, Rick Thomas wrote: > I just tried this using the two-part uSD-card image at [1]. The > problem is still present. Can anyone suggest which of the ethernet > drivers to try in the long list it says is available? > > Thanks! > Rick > > [1] https://d-i.debian.org/daily-image

Bug#982270: linux: [armhf] several imx6 systems unable to detect ethernet

: 2021-05-30 00:09 On Thu, Feb 11, 2021, at 10:56 AM, Vagrant Cascadian wrote: > Control: reassign 982270 linux > Control: retitle 982270 linux: [armhf] several imx6 systems unable to > detect ethernet > Control: found 982270 5.10.13-1 > > On 2021-02-07, Rick Thomas wrote:

Bug#785419: Bug#855203: hwclock-set: Synchronize from hwclock despite systemd presence

sign it to util-linux. > > Is the problem still present? > > Further: > > On Fri, Mar 17, 2017 at 07:55:31PM +0100, Lukas Wunner wrote: > [...] > > @Rick Thomas: Could you verify if the attached patch solves this issue > > for you? > > Were you able to test the pro

Bug#741663: G4 MDD report (finally) Re: Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

task yet. Hope this helps! Rick On Tue, Apr 27, 2021, at 3:55 PM, Rick Thomas wrote: > > > On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> > > On 4/27/21 8:54 AM, Rick Thomas wrote: > > > I'll look around and see if I have any MDD (mi

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

Hi William! On Thu, Apr 29, 2021, at 11:05 AM, William Bonnet wrote: > > The PowerMac G5 users on this list are kindly asked to confirm the bug > > has been fixed. Until then, I'll reopen it. > > I am running the latest version (5.10.0-6-sparc64-smp #1 SMP Debian > 5.10.28-1 (2021-04-09)

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> > On 4/27/21 8:54 AM, Rick Thomas wrote: > > I'll look around and see if I have any MDD (mirror drive door -- the type > > in the > > original bugreport) machines. If so, I'll try to find some time

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

On Mon, Apr 26, 2021, at 10:45 PM, John Paul Adrian Glaubitz wrote: > On 4/27/21 2:07 AM, Rick Thomas wrote: > > I've got the latest (Apr 17) running on my G5 right now. No problems. > > Rick, you should just confirm that this particular problem is fixed but I > assume >

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

I've got the latest (Apr 17) running on my G5 right now. No problems. Rick rbthomas@kmac:~$ cat /proc/version Linux version 5.10.0-6-powerpc64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.28-1

Bug#985196: haveged: OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working

Package: haveged Version: 1.9.14-1 Severity: normal Dear Maintainer, I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to Bullseye and now haveged crashes. $ sudo service haveged status * haveged.service - Entropy Daemon based on the HAVEGE algorithm Loaded: loaded

Bug#982270: installation-reports: Installing Debian Bullseye on Cubox-i4 - installer finds no ethernet

Package: installation-reports Severity: important 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)? * What was the outcome of

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

As I said, simply adding --no-guess-python to ORPHANOPTS does take care of the immediate problem of wanting to delete deluge, but in exchange, it opens up a potential can of worms when there is a python package that is indeed an orphan, which would then not be deleted by upgrade-system. So,

Bug#918755: Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

ote: > la 26. jouluk. 2020 klo 21.30 Rick Thomas (rbtho...@rcthomas.org) kirjoitti: > > > > Package: upgrade-system > > Version: 1.7.3.1 > > Severity: normal > > > > --- Please enter the report below this line. --- > > > > The package "deluge&

Bug#918755: [deborphan] deborphan --guess-all --libdevel wants to remove python-cffi-backend despite it being needed by deluge

Package: deborphan Version: 1.7.31 --- Please enter the report below this line. --- I have manually installed the "deluge" package, which after a chain of depends, requires python-cffi-backend.  However, as can be seen from the following script, deborphan thinks it's not needed.  WTF?

Bug#978158: [upgrade-system] upgrade-system wants to delete package deluge and everything it depends on

Package: upgrade-system Version: 1.7.3.1 Severity: normal --- Please enter the report below this line. --- The package "deluge" is manually (i.e. not "auto") installed on my system.  I use it daily. But when I try to run "upgrade-system" it lists deluge and a bunch of other packages that

Bug#962921: apticron: Use of tempfile(1) produces a warning message

Package: apticron Version: 1.2.3+nmu1 Followup-For: Bug #962921 Dear Maintainer, This produces an email every time apticron runs. Not useful. Thanks for your attention! Rick -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (100,

Bug#971069: ntpsec: why does poll not go beyond 256 even though maxpoll is set to 10?

Package: ntpsec Version: 1.1.9+dfsg1-4 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I don't want to bother the national ntp pool servers more often than necessary. * What exactly did you

Bug#958649: installation-reports: On PowerMac G4 Debian-Ports installer fails to find PATA disks unless a USB drive is also present

Package: installation-reports Followup-For: Bug #958649 I forgot to include the partion information... Her it is: rbthomas@grey:~$ sudo mac-fdisk -l /dev/sda ; lsblk /dev/sda #type name length base ( size ) system /dev/sda1

Bug#958649: installation-reports: On PowerMac G4 Debian-Ports installer fails to find PATA disks unless a USB drive is also present

Package: installation-reports Severity: normal -- Package-specific info: Boot method: CD Image version: https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-powerpc-NETINST-1.iso Date: Apr 22 18:44 PDT Machine: PowerMac G4 Silver "PowerMac 3,5" Partitions: Base System

Bug#958527: installation-reports: Successful install of Debian Ports on PowerMac G5

Package: installation-reports Severity: normal -- Package-specific info: Boot method: CD Image version: https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-ppc64-NETINST-1.iso Date: Machine: PowerMac G5 "PowerMac7,3" Partitions: rbthomas@kmac:~$ df -Tl | grep -v tmpfs

Bug#924192: Is this fix going to make it into Buster any time soon?

> On Sep 21, 2019, at 12:13 PM, Richard Laager wrote: > > On 9/21/19 7:22 AM, Rick Thomas wrote: >> I’d really like to see this fix make it into Debian Buster! >> Any chance of that? > > I dropped the ball on this before the Buster release, for lack of time. >

Bug#924192: Is this fix going to make it into Buster any time soon?

I’d really like to see this fix make it into Debian Buster! Any chance of that? Thanks! Rick

Bug#934974: u-boot: usb start fails on sheevaplug in u-boot 2019.01

I have a sheevaplug that has been on the shelf for a couple years because it appeared to be bricked. I decided to try to unbrick it to see if I could help with these tests. Unfortunately when I plug it in and connect it to a PC running Debian Buster with the micro-USB cable, there is no

Bug#934040: tasksel: doesn't provide transitional package for task-print-server

I second this recommendation! Rick > On Aug 6, 2019, at 4:25 AM, Raphaël Halimi wrote: > > Package: tasksel > Version: 3.54 > > Hi, > > Following #696658, task-print-server was renamed to task-print-service. > > Running "apt-get dist-upgrade" on current Sid tries to remove >

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

Thanks, yes, that did the trick. I’ve installed it on one of my test computers. It seems to work fine. I’ve tried a couple of things that should trigger the bug, if it’s still there. In particular, rebooting the computer then examining the journal shows that it does get to poll all of the

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

Hi Richard, I’m sorry that I was not able to try that patch for you. However, I was able to download and (with a lot of help from Hal Murray) build the latest git version. It worked a treat and properly handled the time lag between ntpsec starting and dhcp finishing. Let me know if there’s

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

> On Mar 19, 2019, at 10:18 AM, Richard Laager wrote: > > Attached is an untested debdiff. This is the upstream change refreshed > to apply to the package. You should be able to apply it and build a > package locally like this: > > sudo apt update > sudo apt install build-essential

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

Thanks! I’ll give it a try tonight… Rick > On Mar 19, 2019, at 10:18 AM, Richard Laager wrote: > > Attached is an untested debdiff. This is the upstream change refreshed > to apply to the package. You should be able to apply it and build a > package locally like this: > > sudo apt update >

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

> On Mar 14, 2019, at 1:04 AM, Richard Laager wrote: > > I forwarded your bug upstream: > https://gitlab.com/NTPsec/ntpsec/issues/577 Hi! I’m sorry to take so long getting back. I wanted to re-do my experiments in a standard environment that your would be able to reproduce easily. Here

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

Thanks Richard, I’ll see if I can set up that experiment(s) and report back ASAP. Would unplugging/replugging the ethernet cable work for steps 2 and 4… Enjoy! Rick > On Mar 11, 2019, at 2:53 PM, Richard Laager wrote: > > Can we narrow this down to a reproducer? It sounds like something like

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

Hi Richard, My observations follow your quote… > On Mar 11, 2019, at 12:30 PM, Richard Laager wrote: > > On 3/10/19 4:11 AM, Rick Thomas wrote: >> If ntpsec implemented the "preempt" option on "peer" directives, the >> first "peer" w

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

> On Mar 11, 2019, at 12:46 AM, Rick Thomas wrote: > > Examining the journal carefully, (specifically the lines labeled “Mar 11 > 00:23:44”, > it looks like the [Install] stanza isn’t the right place to put the “After” > “Wants” lines. > > I’ll keep looking for

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

Hi Tony! I’m not sure if I’m doing it right, but here’s what I did and what happened… What I did: Edited /lib/systemd/system/ntpsec-systemd-netif.path Here’s a diff > rbthomas@cube:~$ diff -c2 /SAVE//lib/systemd/system/ntpsec-systemd-netif.path > /lib/systemd/system/ntpsec-systemd-netif.path >

Bug#924192: ntpsec: at boot ntpsec starts before DNS is available

Package: ntpsec Version: 1.1.3+dfsg1-2 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? the /etc/ntpsec/ntp.conf file (attached) has two "pool" directives and no "server" directives. So it

Bug#889290: If NTP is installed, then systemd-timesyncd should be disabled.

Version: 232-25+deb9u4 has the file Package: systemd Version: 239-11 does not have the file Enjoy! Rick > On Oct 31, 2018, at 3:07 AM, Rick Thomas wrote: > > Is it possible to disable systemd-timesyncd whenever ntp is

Bug#889290: If NTP is installed, then systemd-timesyncd should be disabled.

Is it possible to disable systemd-timesyncd whenever ntp is installed? Apparently, according to Jozsef’s contribution to this bug, the openntpd package has figured out how to do this. Can the same mechanism (whatever it is) be used in the ntp package? Thanks! Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

On Sep 9, 2018, at 1:59 AM, Wolfram Sang wrote: > On Sat, Sep 08, 2018 at 02:48:01PM -0700, Rick Thomas wrote: >> Thanks! Yes, I’ll give it a try. > > Note: You can either build the v4.19-rc1 tar ball which has the patch > already included. Or you can take your Deb

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

Thanks! Yes, I’ll give it a try. On Sep 8, 2018, at 6:51 AM, Salvatore Bonaccorso wrote: > Hi, > > On Mon, Sep 03, 2018 at 11:38:32PM -0700, Rick Thomas wrote: >> Hi Mathieu, >> >> I’m sorry that I don’t have the expertise to apply a patch and build >> a kern

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

Hi Mathieu, I’m sorry that I don’t have the expertise to apply a patch and build a kernel. However, if someone who does have that expertise can build a “.deb’ file and tell me where to download it, I’ll be happy to test and provide detailed feedback. Another possibility, of course, would be

Bug#615646: [installation-guide] How do I know which CD has the package I need?

On Jul 28, 2018, at 10:50 PM, Holger Wansing wrote: > +Also, keep in mind: if the CDs/DVDs you are using don't contain some packages > +you need, you can always install that packages afterwards from your running > +new Debian system (after the installation has finished). If you need to know, >

Bug#615646: [installation-guide] How do I know which CD has the package I need?

On Jul 28, 2018, at 10:44 AM, Holger Wansing wrote: > > Robert Cymbala wrote: >> QUESTION: >> I burned the first fifteen (15) CD's and GNU/Emacs, which I want to >> install, >> is not on them. How do I find out which CDs I need to burn? (There are 37 >> more in

Bug#904525: release-notes: Links to buster release notes don't work

Package: release-notes Severity: normal Dear Maintainer, On webpage https://www.debian.org/releases/buster/releasenotes There are a bunch of links that are claimed to be for draft release notes for Buster. Unfortunately, all of them wind up at “Page not found”. Is this deliberate? Or is

Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

On Jun 12, 2018, at 8:56 PM, Ben Hutchings wrote: >> So, please, at the end, where it tells the reboot message, add >> a third button that shuts down / powers off the system instead >> of rebooting. > > Still, I do agree that this would be useful in general. Especially if it could be

Bug#896638: debian-cd: Unable to build CD image with unsigned repository

On Apr 22, 2018, at 1:43 PM, Vagrant Cascadian wrote: > Package: debian-cd > Severity: normal > Tags: patch > Control: block 879642 by -1 > > With recent changes to apt requiring signed repositories, simple-cdd is > unable to build an image, as it dynamically generates an

Bug#854822: marked as done (installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk")

Great! Is there an installer image somewhere I can test this with on my Cubox-i4x4 ? Thanks! Rick On Jul 15, 2017, at 3:21 PM, Debian Bug Tracking System wrote: > Your message dated Sat, 15 Jul 2017 22:17:18 + > with message-id

Bug#854822: installation-report: U-boot not correctly installed when partitioning with "Guided - use entire disk"

On Feb 10, 2017, at 12:43 PM, Cyril Brulebois wrote: > Hi, > > Karsten Merker (2017-02-10): >> when using the "Guided - use entire disk" option, partman by >> default clobbers the boot sector and the area after it (where >> u-boot is located) to make sure

Bug#834974: Info received (installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install)

Oooops! syslog is mode 600, and I wasn’t root when I created the cpio archive. Here is is syslog.gz Description: GNU Zip compressed data Sorry! Rick On Jun 24, 2017, at 2:23 PM, Cyril Brulebois <k...@debian.org> wrote: > Hi again, > > Rick Thomas <rbtho...@pobox.com&g

Bug#834974: Info received (installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install)

On Jun 24, 2017, at 8:41 AM, Cyril Brulebois <k...@debian.org> wrote: > Hi Rick, > > Rick Thomas <rbtho...@pobox.com> (2017-06-23): >> I re-installed u-boot on the uSDcard. And with that, it booted up a >> treat. >> >> So somehow the u-bo

Bug#834974: Info received (installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install)

I re-installed u-boot on the uSDcard. And with that, it booted up a treat. So somehow the u-boot binary on the uSDcard is getting clobbered in the installation process. Rick

Bug#834974: installation-reports: Stretch 9.0.0 on Cubox-i4Pro fails to boot after install

Package: installation-reports Followup-For: Bug #834974 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I was attempting a test installation of the new Stretch release. * What exactly did you do (or not do)

Bug#861326: ntp: please put ntp vers 1:4.2.8p10+dfsg-1 in jessie-backports. It has important security and bug fixes.

Package: ntp Version: 1:4.2.6.p5+dfsg-7+deb8u2 Severity: wishlist Dear Maintainer, NTP versin 1:4.2.8p10+dfsg-1 has several important security and bug fixes. It should be available for jessie users. Would it be possible to put it in jessie-backports? Thanks! -- System Information: Debian

Bug#856441: Please restore OpenRD support - works, yay! also on openrd ultimate

On 03/25/17 17:40, Rick Thomas wrote: On 03/08/17 17:44, Vagrant Cascadian wrote: On Feb 28, 2017, at 6:39 PM, Martin Michlmayr <t...@cyrius.com> wrote: Debian introduced OpenRD images and later removed them because the stopped working (see #837629). A fix has now been posted up

Bug#856441: Please restore OpenRD support - works, yay!

rdware support. If testing goes well, we'll see what the release team thinks... Rick Thomas has offered to test on the OpenRD Ultimate and (I believe) Client. And Phil Hands too. Yay! live well, vagrant Sorry it took me so long to get to this test. Real-life's a demanding mistress! I

Bug#856441: Please restore OpenRD support

On Mar 22, 2017, at 4:00 AM, Philip Hands <p...@hands.com> wrote: > Rick Thomas <rbtho...@pobox.com> writes: > >> On Mar 10, 2017, at 7:34 AM, Philip Hands <p...@hands.com> wrote: >> >>> Vagrant Cascadian <vagr...@debian.org> writes: >>

Bug#856441: Please restore OpenRD support

On Mar 10, 2017, at 7:34 AM, Philip Hands wrote: > Vagrant Cascadian writes: > >>> On Feb 28, 2017, at 6:39 PM, Martin Michlmayr wrote: Debian introduced OpenRD images and later removed them because the stopped working (see

Bug#856441: Please restore OpenRD support

n > the OpenRD, the one provided by Debian is much more modern. > > On the other hand, there are few OpenRD users, so this is not high > priority. > > I haven't spoken to the release team but in the past they have been > supportive towards changes for hardware support. >

Bug#854946: ntp: please backport ntp version from stretch to jessie-backports

Package: ntp Version: 1:4.2.8p9+dfsg-2.1 Severity: wishlist Dear Maintainer, It would sure be nice to have the 1:4.2.8p9 version of ntp available for Jessie. Thanks for your consideration!

Bug#842040: Please add https support

On Nov 18, 2016, at 10:22 AM, Martin Michlmayr wrote: > * Philipp Kern [2016-11-18 17:19]: >>> Thanks for the CC. I just added wget-udeb and it adds 345 KB, >>> which breaks the orion5x-qnap image. However, this image is really >>> quite a special case and

Bug#837629: OpenRD* with debian's u-boot 2016.09

On 11/02/16 10:38, Vagrant Cascadian wrote: I've uploaded u-boot 2016.11~rc3 to the cascadia.debian.net repository. I won't hold my breath, but give it a try... Good thing you didn't hold your breath. I tried it. Same result as before: No response after "reset". I think I heard that

Bug#837629: OpenRD* with debian's u-boot 2016.09

On Nov 2, 2016, at 10:38 AM, Vagrant Cascadian wrote: > I've uploaded u-boot 2016.11~rc3 to the cascadia.debian.net > repository. I won’t hold my breath, but give it a try... I will. No promises on the target date, but “soon”! (-; > Another option which might help debug

Bug#837629: OpenRD* with debian's u-boot 2016.09

On Oct 5, 2016, at 1:26 PM, Vagrant Cascadian <vagr...@debian.org> wrote: > On 2016-10-03, Rick Thomas wrote: >> On Oct 1, 2016, at 3:39 PM, Vagrant Cascadian <vagr...@debian.org> wrote: >>> On 2016-09-17, Rick Thomas wrote: >>>> On Sep 16, 2016, at 3:19

Bug#837629: OpenRD* with debian's u-boot 2016.09

On Oct 5, 2016, at 1:26 PM, Vagrant Cascadian wrote: > And now uploaded 2016.11~rc1 to my "UNRELEASED" repository, please test > that… Will do. Sometime this weekend. > >> let me know if there’s anything more I can do to help… > > If it's not fixed in 2016.11~rc1, the

Bug#837629: OpenRD* with debian's u-boot 2016.09

On Oct 1, 2016, at 3:39 PM, Vagrant Cascadian <vagr...@debian.org> wrote: > On 2016-09-17, Rick Thomas wrote: >> On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian <vagr...@debian.org> wrote: >>> https://bugs.debian.org/837629 >>> >>> If it can't be f

Bug#837629: OpenRD* with debian's u-boot 2016.09

OK. I’ll give it a try. More when I know more. Rick On Oct 1, 2016, at 3:39 PM, Vagrant Cascadian <vagr...@debian.org> wrote: > On 2016-09-17, Rick Thomas wrote: >> On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian <vagr...@debian.org> wrote: >>>

Bug#837629: OpenRD* with debian's u-boot 2016.09

On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian wrote: > There is at one report of an OpenRD ultimate that would not boot with > the 2016.09~rc2 version of u-boot in debian. Uploaded 2016.09+dfsg-1 to > unstable a few days ago. Would you be able to confirm if OpenRD variants

Bug#837629: u-boot 2016.09 in Debian

On Sep 15, 2016, at 10:43 PM, Vagrant Cascadian <vagr...@debian.org> wrote: > Control: severity 837629 serious > > On 2016-09-14, Rick Thomas wrote: >> On Sep 14, 2016, at 5:31 PM, Vagrant Cascadian <vagr...@debian.org> wrote: >> >>> Worst cas

Bug#837629: u-boot 2016.09 in Debian

> On Sep 12, 2016, at 2:37 PM, Vagrant Cascadian wrote: > > On 2016-09-10, Karsten Merker wrote: >> On Mon, Sep 05, 2016 at 09:22:23AM -0700, Vagrant Cascadian wrote: >>> The current u-boot packages in Debian experimental (2016.09~rc2+dfsg1-1) >>> appear to be working fine

Bug#837629: u-boot 2016.09 in Debian

On Sep 14, 2016, at 5:31 PM, Vagrant Cascadian wrote: > Worst case, we have to remove it from stretch again if it really is that > bad... I’ll certainly do the test. If it still doesn’t work on the OpenRD, I would not remove it from stretch just yet. Frankly, there just

Bug#837629: u-boot 2016.09~rc2+dfsg1-1 bricks my openrd ultimate

Package: u-boot Version: 2016.09~rc2+dfsg1-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? As requested by Vagrant I'm testing u-boot 2016.09~rc2+dfsg1-1 on my OpenRD Ultimate machine. *

Bug#836925: u-boot: installation report for u-boot and u-boot-tools 2016.09~rc2+dfsg1-1

On Sep 12, 2016, at 2:30 PM, Vagrant Cascadian <vagr...@aikidev.net> wrote: > Control: severity 836925 important > > On 2016-09-07, Rick Thomas wrote: >> I installed the new u-boot using the procedure in >> /usr/share/doc/u-boot/README.Debian >> >

Bug#836925: u-boot: installation report for u-boot and u-boot-tools 2016.09~rc2+dfsg1-1

Package: u-boot Version: 2016.09~rc2+dfsg1-1 Severity: normal I installed u-boot and u-boot-tools from the Debian experimental repo -- versions 2016.09~rc2+dfsg1-1 I installed the new u-boot using the procedure in /usr/share/doc/u-boot/README.Debian The newly installed u-boot loaded and

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

On Sep 4, 2016, at 3:12 AM, Rick Thomas <rbtho...@pobox.com> wrote: >> On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagr...@debian.org> wrote: >> >>> I'd be curious if you re-install and delete each partition individually >>> and re-create manua

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

> On Sep 2, 2016, at 6:33 PM, Rick Thomas <rbtho...@pobox.com> wrote: > > > On Sep 2, 2016, at 4:40 PM, Gunnar Wolf <gw...@debian.org> wrote: > >> Can somebody confirm whether the Jessie >> installer actually works reliably on this machine? (that is, w

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

On Sep 2, 2016, at 6:30 PM, Rick Thomas <rbtho...@pobox.com> wrote: > > On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagr...@debian.org> wrote: > >> I'd be curious if you re-install and delete each partition individually >> and re-create manually vs. u

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

On Sep 2, 2016, at 4:40 PM, Gunnar Wolf wrote: > Can somebody confirm whether the Jessie > installer actually works reliably on this machine? (that is, whether > it's always been broken or we have a regression) I’ll give that a try as well over the weekend. Let you know what

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian wrote: > I'd be curious if you re-install and delete each partition individually > and re-create manually vs. using one of the auto-partitioning methods. I’ll give this a try over the weekend and report back what I find. Is it

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

For what it’s worth, I just tried booting with an HDMI monitor connected to see if the silence on the serial-port was just a matter of console messages being directed to the HDMI video port instead. Still no go. Silence all-round. Rick > On Aug 22, 2016, at 9:15 PM, Rick Thomas <

Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

I can confirm this problem. I just got thru running a “stretch” install on my test Cuboxi4Pro with ingredients from: > wget > http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz > wget >

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

On Aug 17, 2016, at 12:09 AM, Guus Sliepen wrote: > What you then have to do is clean up after the > kernel, by adding the following to /etc/network/interfaces: > > pre-up ip -6 a flush dev $IFACE mngtmpaddr > > You can add this to either the inet or inet6 stanza.

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

It may be worth noting that after “updateinitramfs -u” I don’t see /etc/sysctl.conf in the new initrd file: > root@sheeva:~# lsinitramfs -l /boot/initrd.img | grep sysctl > -rwxr-xr-x 205 root root0 Apr 17 15:03 sbin/sysctl So if the kernel is picking up the RA before

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

On Aug 16, 2016, at 4:51 PM, Guus Sliepen <g...@debian.org> wrote: > On Tue, Aug 16, 2016 at 03:56:56PM -0700, Rick Thomas wrote: > >>> Another option is to add the following line to /etc/systl.conf: >>> >>> net.ipv6.conf.all.accept_ra=0 >> &

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

> On Aug 16, 2016, at 1:57 PM, Guus Sliepen <g...@debian.org> wrote: > > On Tue, Aug 16, 2016 at 01:07:15PM -0700, Rick Thomas wrote: > >> Thanks Pascal! > > Indeed thanks, now I have less explaining to do :) And thank you Guus :) Now I understand a lot more

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

Thanks Pascal! On Aug 16, 2016, at 12:59 AM, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote: > Le 16/08/2016 à 09:03, Rick Thomas a écrit : >> >> Aug 14 17:02:41 sheeva systemd[1]: Starting Raise network interfaces... >> Aug 14 17:02:46 sheeva ifup[893]: /sbin/ifup: w

Bug#832713: closed by Martin Pitt <mp...@debian.org> (Bug#832893: fixed in systemd 231-2)

On Aug 14, 2016, at 11:13 PM, Michael Biebl wrote: > Rick, if you comment out MemoryDenyWriteExecute=yes in your service > files in /lib/systemd/system, is the problem gone? Yeah, that seems to make the problem go away. Rick

Bug#834376: ifupdown: boot console says 'Failed to start Raise network interfaces' yet interface is up

Package: ifupdown Version: 0.8.13 Severity: normal Dear Maintainer, Updated to latest debian Sid See attached screenlog of boot. note error message quoted in subject line After boot is completed we see: rbthomas@sheeva:~$ systemctl status networking.service * networking.service - Raise

Bug#832713: closed by Martin Pitt <mp...@debian.org> (Bug#832893: fixed in systemd 231-2)

Sorry, it’s not fixed in 231-2… Please see attached boot log. Rick screenlog.xz Description: Binary data

Bug#816959: apticron: Error with packages on hold.

Package: apticron Version: 1.1.58 Followup-For: Bug #816959 Dear Maintainer, Me too... -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')

Bug#832713: systemd: after "systemd (231-1) unstable" update systemd-jurnald.service fails to start

On Aug 12, 2016, at 9:21 AM, Pete Batard wrote: > Okay. I have now gone through a dpkg -i install of all the (non dbgsym) .deb > I see on your server, and also issued a reboot for good measure, but I still > see the same problem with journald being failed, along with dependent

  1   2   3   4   5   6   7   >