date:20180426

Archiving the attic folders from d-i for ports

2018-04-26 Thread John Paul Adrian Glaubitz

(Re-send because I forgot debian-ports-devel@alioth is dead,
 please reply to debian-boot@)

Hi!

I was pointed at Steve's mail yesterday mentioning that he moved
the non-attic repositories of debian-installer to salsa [1].

Since there are still some repositories that we need for debian-ports
in the attic, I was wondering whether we should take care of the
attic stuff and move it over to salsa or github.

FWIW, we are in the progress of moving the sparc* and ppc* ports
which aren't on GRUB yet fully over. In fact, GRUB works fine on
all SPARC boxes we have tested so far, so at least silo-installer
won't be needed anymore in the future. Still, I think we should
archive everything.

Adrian

> [1] https://lists.debian.org/debian-boot/2018/04/msg00253.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Archiving the attic folders from d-i for ports

2018-04-26 Thread John Paul Adrian Glaubitz

Hi!

I was pointed at Steve's mail yesterday mentioning that he moved
the non-attic repositories of debian-installer to salsa [1].

Since there are still some repositories that we need for debian-ports
in the attic, I was wondering whether we should take care of the
attic stuff and move it over to salsa or github.

FWIW, we are in the progress of moving the sparc* and ppc* ports
which aren't on GRUB yet fully over. In fact, GRUB works fine on
all SPARC boxes we have tested so far, so at least silo-installer
won't be needed anymore in the future. Still, I think we should
archive everything.

Adrian

> [1] https://lists.debian.org/debian-boot/2018/04/msg00253.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: FTBFS with TeX Live 2018

2018-04-26 Thread Cyril Brulebois

Hi Hilmar,

Hilmar Preuße  (2018-04-26):
> This is the patch for installation-howto.po.

Thanks, I've just pushed it:
| Committed revision 71074.

> Unfortunately the build fails later on the nl localizsation:
> 
> xelatex -interaction=batchmode install.nl.profiled.tex
> xelatex failed
> install.nl.profiled.tex:75: Emergency stop.
> install.nl.profiled.tex:75: leading text: \maketitle
> /home/hille/installation-guide-20170614/build/build.tmp.nl.i386/dblatex/tmpUw9ouC
> not removed
> 
> Unfortunately the temporary files /are/ removed, which makes debugging
> a little bit harder. ;-(

Yes, one needs to tell it to stop doing so… (I ran into that issue in
the past as well)…

But I don't seem able to replicate it in a sid devel chroot (not a
minimal, sbuild-like one). Maybe you ran out of space, or some similar
issue? (I'm seeing 645M in the build tree after a successful build.) You
could try with -j1 to see if that helps.

Also, we should catch up with recent-ish debhelper compat level at some
point, 6 is starting to feel quite old…

> --- po/ja/installation-howto.po_orig  2016-05-31 17:32:53.0 +0200
> +++ po/ja/installation-howto.po   2018-04-26 10:46:10.201154031 +0200
> @@ -129,7 +129,7 @@
>  msgstr ""
>  "netinst CD ?? ??  
> ??"
>  "?? CD 
> ???"
> -"?`netinst'
>  ??"
> +"?'netinst'
>  ??"
>  
> "??"
>  "?  
> ?"
>  
> "??
>  CD ??"

[ Your mail client announced the patch as us-ascii, which I think it
  wasn't. :) ]


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Salsa

2018-04-26 Thread Cyril Brulebois

Hi,

Steve McIntyre  (2018-04-26):
> On Thu, Apr 26, 2018 at 04:10:40AM +0200, Cyril Brulebois wrote:
> >> bak.debootstrap
> >
> >That one should probably go away?
> 
> Yup, good call. Didn't see that one in the list, I just did '*.git'
> basically. Now deleted.

Thanks!

> >I've updated .mrconfig to point to the new location; I'll probably
> >remove the “deleted = true” entries as they are for packages in the
> >attic; and those are doubly deprecated as they're going to be
> >archived now anyway.
> 
> Yup.

Done. Current mr status outputs this last line:
| mr update: finished (100 ok)

I've also updated all Vcs-* fields in the master branch of each
repository.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Salsa

2018-04-26 Thread Cyril Brulebois

Hi,

I've just checked the list you provided below with what's in my local
copy, deployed with .mrconfig:

Steve McIntyre  (2018-04-26):
> bak.debootstrap

=> deleted as mentioned earlier.

> d-i

=> can go away (alioth generated for all git-based projects)?

> daily-build-logs

=> repository is likely corrupted, not sure it's recoverable; it might
   make sense to scratch it since its main purpose is to make it easy
   to find what broke when daily builds regress. Most useful short term
   anyway, IMHO.

> kadit-playbooks
> kadit

=> both not mentioned on purpose


So I think we're (almost) good here.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Remote Debian installation assistance for newbies using WireGuard VPN

2018-04-26 Thread ST

On Wed, 2018-04-25 at 18:17 +0200, Philip Hands wrote:
> ST  writes:
> 
> > On Wed, 2018-04-25 at 14:50 +0200, Philip Hands wrote:
> >> ST  writes:
> >> 
> >> > Hello Debian Install System Team,
> >> >
> >> > there used to be Linux install parties - a very cool event in itself and
> >> > a way to bring new users into community. However it is not so easy to
> >> > organize and it is somewhat limiting in time and space.
> >> >
> >> > Several weeks ago I learned about the kernel-space VPN - WireGuard [1]
> >> > and was so positively shocked by the ease of it's configuration/use [2]
> >> > so that I don't stop to think how it can be effectively utilized.
> >> >
> >> > Today I was thinking whether it would be possible to use this technology
> >> > to enable an experienced Linux user to help a fellow newbie to install
> >> > Debian on his Windows box?...
> >> >
> >> > The idea is to add an "Remote assistance mode" into win32-loader. Once
> >> > toggled - it will preseed and run Debian Installer (after reboot)
> >> > without any interaction until it:
> >> > 1. creates a WG interface,
> >> > 2. obtains an IP from a (not yet extent) Debian WireGuard VPN server [3]
> >> > (the assisting Linux profi also should be part of this VPN so he can SSH
> >> > to the newbie through NAT).
> >> > 3. runs SSH server listening on that IP.
> >> > 4. generates a short random password for the root user and displays it
> >> > together with its IP from step #2 on the monitor of the newbie. This
> >> > information (IP and root's password) are communicated by newbie to his
> >> > Linux profi friend by phone/sms/etc..
> >> >
> >> >>From this point on the Linux profi can SSH to the box and continue the
> >> > installation process in text mode.
> >> >
> >> > Is something like this possible?
> >> 
> >> I've not yet used WireGuard, but from what I can see one needs a unique
> >> key per client to be known to the server (perhaps there's a way of
> >> telling it not to care).  Also, the examples around the place also seem
> >> to suggest that one needs a UDP port per connection.
> >> 
> >> Also, the wireguard.com front page does currently say:
> >> 
> >>   WireGuard is not yet complete. _You should not rely on this code._
> >> 
> >> Anyway, I don't see that one actually needs WireGuard to implement it.
> >> 
> >> A similar result could be achieved by configuring the new system to ssh
> >> to a server somewhere, and either have that connection used for the
> >> remote control, or have ssh also do port-forwarding back to the new
> >> installation.
> >
> > Indeed?!... I'm positively shocked once again... Never knew it could be
> > possible. Let's say we have a newbie (with a private IP - N which is
> > behind NAT) and the same for a profie with IP P. And a publicly visible
> > server with the IP S. Let's say both can SSH to S:22 and know each
> > others' passwords/keys.
> >
> >  Could you, please, describe in details how one can implement both
> > approaches, namely:
> >
> > 1. "to ssh to a server somewhere, and either have that connection used",
> > i.e. `ssh newbie@S:22`... so what now? How profi can get through to N?
> 
> Many years ago I used to plumb things like this together with expect,
> but there's bound to be a better way to do it these days -- tmate.io
> (mentioned elsewhere in the thread) seems like it might be part of such
> a solution.  I doesn't trike me as the optimal approach though.
> 
> > 2. "or have ssh also do port-forwarding back to the new installation"
> > could you, please show the sequence of commands to achieve this?
> 
> One would use something like this on the target system:
> 
>   ssh -R 0:localhost:22 newbie@S
> 
> which leaves you with the challenge of telling the "profi" the port
> that's been allocated, which is probably scriptable on the server
> somehow,

It sounds like a great approach. The port should be allocated randomly
from available ports instead of the VPN IP form step #2 above. This
random port together with the random root password will be displayed on
newbie's monitor. Both credentials he will pass by phone to the profi.

>  at which point they can do what boils down to:
> 
>   ssh -J profie@S:22 -p $DYN_PORT root@localhost
> 
> which should jump via the server, up the reverse port forward, and then
> onto the target.
> 
> Making that so that nobody gets to do anything nasty on the server

This should be no problem: there will be two accounts (with known
private/public keys) - newbie and profi. On the newbie account you'll
block absolutely every possible command (with *) via `visudo`. For the
profi you'll block via `visudo` almost everything except for `ssh`
command with very strict possible arguments which enable only utilizing
the reverse tunnel established by newbies.

>  or to
> connect to the wrong newbie

There is nothing to implement here - if a profi tries to connect to some
other newbie - he will fail, since he doesn't know his local root
password.

I

Re: FTBFS with TeX Live 2018

2018-04-26 Thread Hilmar Preuße

On 22.04.2018 13:11, Adrian Bunk wrote:

Hi,

> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/installation-guide.html
> 
This is the patch for installation-howto.po.

Unfortunately the build fails later on the nl localizsation:

xelatex -interaction=batchmode install.nl.profiled.tex
xelatex failed
install.nl.profiled.tex:75: Emergency stop.
install.nl.profiled.tex:75: leading text: \maketitle
/home/hille/installation-guide-20170614/build/build.tmp.nl.i386/dblatex/tmpUw9ouC
not removed

Unfortunately the temporary files /are/ removed, which makes debugging a
little bit harder. ;-(

Hilmar
-- 
#206401 http://counter.li.org
--- po/ja/installation-howto.po_orig	2016-05-31 17:32:53.0 +0200
+++ po/ja/installation-howto.po	2018-04-26 10:46:10.201154031 +0200
@@ -129,7 +129,7 @@
 msgstr ""
 "netinst CD ã¤ã¡ã¼ã¸ã¯ã ã§ã®  ã®ã¤ã³ã¹ãã¼ã«ã«ä½¿ç¨ããã®ã«"
 "ä¸è¬çãªã¤ã¡ã¼ã¸ã§ãããã®ã¤ã¡ã¼ã¸ã¯ CD ããèµ·åãããããã¯ã¼ã¯è¶ãã«è¿½å "
-"ããã±ã¼ã¸ãã¤ã³ã¹ãã¼ã«ããããã«æå³ããã¦ããã®ã§ã`netinst' ã¨ããååã"
+"ããã±ã¼ã¸ãã¤ã³ã¹ãã¼ã«ããããã«æå³ããã¦ããã®ã§ã'netinst' ã¨ããååã"
 "ã¤ãã¦ãã¾ããã¾ããã¤ã³ã¹ãã¼ã©ãå®è¡ããã®ã«å¿è¦ãªãã½ããã¦ã§ã¢ã³ã³ãã¼ã"
 "ã³ãã¨æå°éã®  ã·ã¹ãã ãæä¾ããåºæ¬ããã±ã¼ã¸ãå«ã¾ãã¦ãã¾"
 "ããå¿è¦ãªãããããã¯ã¼ã¯ãå¿è¦ã¨ããªãããã«ãµã¤ãº CD ã¤ã¡ã¼ã¸ãæã«å¥ãã"


signature.asc
Description: OpenPGP digital signature

Re: Salsa

2018-04-26 Thread Steve McIntyre

On Thu, Apr 26, 2018 at 01:04:55AM +0100, Steve McIntyre wrote:
>On Tue, Apr 24, 2018 at 11:16:04PM +0200, Cyril Brulebois wrote:
>>Hi,
>>
>>Chris Boot  (2018-04-24):
>>> I didn't receive much feedback from the -boot team since I created the
>>> Salsa project and did the initial member import, but I also didn't
>>> remind people about it after those first few emails.
>>
>>Yes, sorry for not having been more proactive on this topic. :(
>>
>>> FWIW I have been using GitLab both personally and at work very
>>> successfully for quite a while now with my generally Git-centric
>>> workflow. I have no recent experience with conversions from other VCS,
>>> and I do understand some people's concerns about whether GitLab is the
>>> best fit for Debian, but I strongly believe that whilst it may require
>>> a bit of a mindset readjustment it's the best thing out there for us.
>>
>>That's very fine. :) I was more wondering about tips and tricks for the
>>actual migration; but apparently Steve is happy to help with setting
>>things up with packages, so I would only have to deal with adapting the
>>l10n commit robot for new URLs.
>
>I've now migrated all 103(!) of the non-attic d-i repos across from
>alioth to salsa, following the pattern
>
> https://anonscm.debian.org/cgit/d-i/$REPO.git
>
>   to
>
> https://salsa.debian.org/installer-team/$REPO

Forgot last night; I've just pushed a merge request for AliothRewriter
for the 102 repos too. anonscm.d.o URLs should point to salsa shortly.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

Re: Salsa

2018-04-26 Thread Steve McIntyre

On Thu, Apr 26, 2018 at 04:10:40AM +0200, Cyril Brulebois wrote:
>Steve McIntyre  (2018-04-26):
>
>> In each case, the old alioth repo will now reject pushes. The new
>> repos are each set up to use KGB to announce changes in #debian-boot
>> as previously. I've not (yet) spent any time on updating all the
>> debian/control files to point at salsa, or updated mr configs or
>> anything else.
>> 
>> The repos involved are:
>> 
>> […]
>> bak.debootstrap
>
>That one should probably go away?

Yup, good call. Didn't see that one in the list, I just did '*.git'
basically. Now deleted.

>I've updated .mrconfig to point to the new location; I'll probably remove the
>“deleted = true” entries as they are for packages in the attic; and those are
>doubly deprecated as they're going to be archived now anyway.

Yup.

>URLs on dillon (d-i.debian.org host) have been updated to point to salsa.
>
>A key has been generated there specifically for salsa, ~/.gitconfig has been
>updated to rewrite https into ssh to push using ssh, and I've set up a
>di-l10n-guest account as previously on alioth. I'm told we could be using
>deploy keys, but from a quick glance they seem to work on a project level
>(rather than on the group leve), and I'm not toying with salsa's API right
>away. Also, https://wiki.debian.org/Salsa/Doc#Deployment_keys is in FIXME
>mode. ;) If the di-l10n-guest account remains needed, we should adjust the
>mail address from one of mine to something shared across several people (not
>sure about using debian-boot@ for that…).

ACK.

>A manual l10n-sync script seems to be working just fine, given the log
>and the commits popping up on IRC. The only issue seems to be this, which is
>likely an issue with the package itself:
>| Everything up-to-date
>| - preseed
>|   - Run debconf-updatepo... failed.
>
>
>Migrating away from SVN is still an open task though.

Right. We should get that done next.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Archiving the attic folders from d-i for ports

Archiving the attic folders from d-i for ports

Re: FTBFS with TeX Live 2018

Re: Salsa

Re: Salsa

Re: Remote Debian installation assistance for newbies using WireGuard VPN

Re: FTBFS with TeX Live 2018

Re: Salsa

Re: Salsa

9 matches

Site Navigation

Mail list logo

Footer information