Control: reopen -1
On 3/28/20 6:16 PM, John Paul Adrian Glaubitz wrote:
> On 3/28/20 5:39 PM, Ivo De Decker wrote:
>> This bug wasn't fixed in time for buster. Is it still present in bullseye? If
>> so, it might be good to try to fix it this time.
>
> I fixed the bug upstream [1], so we can safel
Processing control commands:
> reopen -1
Bug #926539 {Done: John Paul Adrian Glaubitz }
[src:linux,rootskel] rootskel: steal-ctty no longer works on at least sparc64
Bug reopened
Ignoring request to alter fixed versions of bug #926539 to the same values
previously set
--
926539: https://bugs.d
Hi,
On Wed, Jun 26, 2019 at 10:18:37PM +0100, James Clarke wrote:
> (Don't know if this is a blocker for the release, but it should at
> least be reviewed before we release IMO, hence the severity)
>
> On Sun, Apr 07, 2019 at 12:53:35AM +0100, Ben Hutchings wrote:
> > On Sat, 2019-04-06 at 21:33
Processing control commands:
> reopen -1
Bug #926539 {Done: Ben Hutchings } [src:linux] rootskel:
steal-ctty no longer works on at least sparc64
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopen
Processing control commands:
> reassign -1 src:linux
Bug #926539 [src:rootskel] rootskel: steal-ctty no longer works on at least
sparc64
Bug reassigned from package 'src:rootskel' to 'src:linux'.
No longer marked as found in versions rootskel/1.128.
Ignoring request to alter fixed versions of bug
Control: reassign -1 src:linux
Control: tags -1 patch
On 4/16/19 1:16 PM, Ben Hutchings wrote:
>> Do you think we could carry a patch in src:linux for the time being?
> [...]
>
> I would rather not do that until it's accepted, as if it that doesn't
> happen we either have to switch back or carry
On 4/16/19 1:16 PM, Ben Hutchings wrote:
>> Do you think we could carry a patch in src:linux for the time being?
> [...]
>
> I would rather not do that until it's accepted, as if it that doesn't
> happen we either have to switch back or carry it forever.
Hmm, okay. Then I don't really have a way
On Tue, 2019-04-16 at 11:47 +0200, John Paul Adrian Glaubitz wrote:
> Hi Ben!
>
> On 4/7/19 1:53 AM, Ben Hutchings wrote:
> > > root@landau:~# cat /proc/consoles
> > > ttyHV0 -W- (EC p )4:64
> > > tty0 -WU (E )4:1
> > > root@landau:~# readlink /sys/dev/c
Hi Ben!
On 4/7/19 1:53 AM, Ben Hutchings wrote:
>> root@landau:~# cat /proc/consoles
>> ttyHV0 -W- (EC p )4:64
>> tty0 -WU (E )4:1
>> root@landau:~# readlink /sys/dev/char/4:64
>> ../../devices/root/f0299a70/f029b788/tty/ttyS0
>
> The inconsistent name
On Sat, 2019-04-06 at 21:33 +0200, John Paul Adrian Glaubitz wrote:
> On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> > My suspicion is that the support multiple consoles in parallel [2]
> > introduced
> > this particular regression. I haven't done any debugging yet though as I'm
> > not sur
On 4/6/19 6:46 PM, John Paul Adrian Glaubitz wrote:
> My suspicion is that the support multiple consoles in parallel [2] introduced
> this particular regression. I haven't done any debugging yet though as I'm
> not sure where to start, I haven't touched the rootskel package before and
> therefore w
Source: rootskel
Version: 1.128
Severity: important
User: debian-sp...@lists.debian.org
Usertags: sparc64
Hello!
I built updated installation images [1] for Debian Ports today and tested
the sparc64 image on our SPARC T5 in an LDOM.
Unfortunately, it seems that the recent changes to rootskel bro
12 matches
Mail list logo
