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
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:
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
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
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
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
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
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
12 matches
Mail list logo
