Re: Readme sanity check

2019-05-17 Thread Paul Sutton



On 18/05/2019 03:33, bw wrote:
> In-Reply-To: <7d98acfd-19b9-ed61-362c-81e714484...@disroot.org>
> 
> ...
>> Would it be possible to someone have a read through...
> 
> I like a good read, never heard of rocksndiamonds though. Could not find 
> the text.  I used ff-esr, chromium with no javascript and links2.  All I 
> get is a very nice page with a lot of disabled controls, and cool 
> tooltips.  Clean links are best, blind links are sucky.
> 
> $ wget --spider 
> https://salsa.debian.org/zleap-guest/rocksndiamondslevels/blob/master/README.md
> Spider mode enabled. Check if remote file exists.
> --2019-05-17 22:29:09--  
> https://salsa.debian.org/zleap-guest/rocksndiamondslevels/blob/master/README.md
> Resolving salsa.debian.org (salsa.debian.org)... 209.87.16.44, 
> 2607:f8f0:614:1::1274:44
> Connecting to salsa.debian.org (salsa.debian.org)|209.87.16.44|:443... 
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/html]
> Remote file exists and could contain further links,
> but recursion is disabled -- not retrieving.
> 
Good point, not quite sure how to resolve this?

Paul


-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Re: Debian Releases

2019-05-17 Thread Peter Ehlert

looking forward to it, thanks

On 5/17/19 1:55 PM, Francisco M Neto wrote:

On Fri, 2019-05-17 at 21:35 +0100, Joe wrote:

Don't forget:

https://bugs.debian.org/release-critical/

I'm gonna cover that on the next post ;-)





Re: Debian Getting started

2019-05-17 Thread Peter Ehlert

good effort, and a much needed type of promotion

thanks

On 5/17/19 2:04 PM, Paul Sutton wrote:

Hi

Following on from Francisco post, I had been thinking about writing
something about getting started for a while.  So decided to just get on
and do it.

http://zleap.net/debian-getting-started/

I am trying to write this from my own view point of being new and
explain how I got started and how others can.  Lot of references to
parts of the Debian Website.

Paul






Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Richard Hector
On 18/05/19 5:17 PM, Aidan Gauland wrote:
> On 18/05/19 11:08 AM, Dominik George wrote:
>>> Can you give sources for your claim about their discrimination?  That
>>> one is new to me.
>> I did. Please read my mails in this thread.
> I have, and I just re-read the articles you gave, and I still do not see
> anything about discrimination by age, or against any group of people,
> only the usual issues with hosting free software on/with non-free
> services (which reason enough to avoid GitHub).
> 

I'm not going to read them again, but IIRC one of them referred to the
GitHub ToC, which contained a bit about restricting accounts to those
over 13 years of age, and claiming this was due to US law (but not
specifying which law).

Richard



signature.asc
Description: OpenPGP digital signature


Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Aidan Gauland
On 18/05/19 11:08 AM, Dominik George wrote:
>> Can you give sources for your claim about their discrimination?  That
>> one is new to me.
> I did. Please read my mails in this thread.
I have, and I just re-read the articles you gave, and I still do not see
anything about discrimination by age, or against any group of people,
only the usual issues with hosting free software on/with non-free
services (which reason enough to avoid GitHub).



Re: Just had to reset/reboot again, total loss of keyboard & mouse

2019-05-17 Thread Felix Miata
Gene Heskett composed on 2019-05-17 23:16 (UTC-0400):

> The first thing I saw as it rebooted was some msgs about hid-common
> This was before recovering the journal on the boot drive.

> So I at least has a clue where the crash is occurring, hid-common.

> What else can I do to nail this down good enough for a bug report?
> sudo grep -R hid-common /var/log/*
> doesn't give a clue.

On what, Stretch? Does /var/log/journal/ exist? If it does, try:

journalctl | grep hid-common
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/



Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Ben Finney
Mark Allums  writes:

> On 5/17/19 2:28 AM, Dominik George wrote:
> >> Please explain, in detail, why.
> > https://mako.cc/writing/hill-free_tools.html
> > https://www.adamhyde.net/another-good-reason-not-to-use-github/
> > https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
>
> I'm not convinced,  Give me more.

If the above articles don't convince you, what would convince you that
has not already been said?

I'm sure you can appreciate that some people have unreasonable demands
for being convinced, and no amount of persuasion is enough. Can you give
an example of what reasonable presentation would be needed to convince
you on this matter?

-- 
 \“Don't worry about people stealing your ideas. If your ideas |
  `\ are any good, you'll have to ram them down people's throats.” |
_o__)—Howard Aiken |
Ben Finney



Just had to reset/reboot again, total loss of keyboard & mouse

2019-05-17 Thread Gene Heskett
The first thing I saw as it rebooted was some msgs about hid-common
This was before recovering the journal on the boot drive.

So I at least has a clue where the crash is occurring, hid-common.

What else can I do to nail this down good enough for a bug report?
sudo grep -R hid-common /var/log/*
doesn't give a clue.

Thanks all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread arne
On Fri, 17 May 2019 17:57:55 +0200
Dominik George  wrote:

> >Does putting software on GitHub give them any kind of claim on the 
> >intellectual property of the software?  
> 
> No.
> 

No, not now

But when, matter of time I guess.

Been there, done that.



Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Dominik George
>Can you give sources for your claim about their discrimination?  That
>one is new to me.

I did. Please read my mails in this thread.

-nik



Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Aidan Gauland
On 17/05/19 7:28 PM, Dominik George wrote:
>>> please do*never*  use GitHub for free software
>> Please explain, in detail, why.
> If discrimination against parts of the community is not enough for you, 
> here's why:
>
> https://mako.cc/writing/hill-free_tools.html
>
> https://www.adamhyde.net/another-good-reason-not-to-use-github/
>
> https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
Can you give sources for your claim about their discrimination?  That
one is new to me.



Re: FW: knockd package long-standing bug

2019-05-17 Thread Brian
On Fri 17 May 2019 at 20:20:03 +, Riccardo Paolo Bestetti wrote:

> > You could also consider just applying the patches which work for you
> > and getting on with life. Bugs have been reported and not responded
> > to. You have done your part; now it is up to someone else who is in
> > a position to do something about it.
> I was only trying to help, or at least find out if I could do it
> easily enough. It seemed like the right thing to do.

I understood that and it is an honorable intention. However, the BTS
is a main point of contact between ordinary users and maintainers. If
there is no outcome there, the channels of communication are limited.

> > Note that the Package Salvaging process "..is only intended for
> > actively taking over maintainership." How an ordinary user would
> > start the process doesn't appear to be documented.
> Actually, it is documented pretty well! It's called an "NMU" [1].

Indeed, an NMU is documented, but it is a process not open to users
as a whole.

-- 

Brian.



Debian Getting started

2019-05-17 Thread Paul Sutton
Hi

Following on from Francisco post, I had been thinking about writing
something about getting started for a while.  So decided to just get on
and do it.

http://zleap.net/debian-getting-started/

I am trying to write this from my own view point of being new and
explain how I got started and how others can.  Lot of references to
parts of the Debian Website. 

Paul


-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Re: Debian Releases

2019-05-17 Thread Francisco M Neto
On Fri, 2019-05-17 at 21:35 +0100, Joe wrote:
> Don't forget:
> 
> https://bugs.debian.org/release-critical/

I'm gonna cover that on the next post ;-)

-- 
[]'s,

Francisco M Neto

GPG: 4096R/D692FBF0


signature.asc
Description: This is a digitally signed message part


Re: Debian Releases

2019-05-17 Thread Joe
On Fri, 17 May 2019 21:20:23 +0100
Paul Sutton  wrote:

> On 17/05/2019 21:05, Francisco M Neto wrote:
> > As the first in a series of (maybe 2) posts about Debian's release
> > cycle, I'vecreated the following post. 
> >
> > I would love to receive any feedback on it.
> >
> > http://fmneto.com.br/en/en/archives/2019/tracking-busters-release/
> >  
> 
> This is excellent and a great introduction to how the Debian release
> process works.  So also good for beginners who may want to start
> helping with Debian. 
> 
> Keep up the good work
> 

Don't forget:

https://bugs.debian.org/release-critical/

-- 
Joe



RE: FW: knockd package long-standing bug

2019-05-17 Thread Riccardo Paolo Bestetti
-Original Message-
From: Brian  
Sent: venerdì 17 maggio 2019 19:21
To: debian-user@lists.debian.org
Subject: Re: FW: knockd package long-standing bug

> You could also consider just applying the patches which work for you and 
> getting on with life. Bugs have been reported and not responded to. You have 
> done your part; now it is up to someone else who is in a position to do 
> something about it.
I was only trying to help, or at least find out if I could do it easily enough. 
It seemed like the right thing to do.

> Note that the Package Salvaging process "..is only intended for actively 
> taking over maintainership."
> How an ordinary user would start the process doesn't appear to be documented.
Actually, it is documented pretty well! It's called an "NMU" [1].

BR,
Riccardo

--
[1] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu



Re: Debian Releases

2019-05-17 Thread Paul Sutton


On 17/05/2019 21:05, Francisco M Neto wrote:
> As the first in a series of (maybe 2) posts about Debian's release cycle, 
> I'vecreated the following post. 
>
> I would love to receive any feedback on it.
>
> http://fmneto.com.br/en/en/archives/2019/tracking-busters-release/
>

This is excellent and a great introduction to how the Debian release
process works.  So also good for beginners who may want to start helping
with Debian. 

Keep up the good work

Paul


-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Debian Releases

2019-05-17 Thread Francisco M Neto
As the first in a series of (maybe 2) posts about Debian's release cycle, 
I'vecreated the following post. 

I would love to receive any feedback on it.

http://fmneto.com.br/en/en/archives/2019/tracking-busters-release/

-- 
[]'s,

Francisco M Neto

GPG: 4096R/D692FBF0


signature.asc
Description: This is a digitally signed message part


Re: using git locally

2019-05-17 Thread mick crane

On 2019-05-17 15:59, Eduardo M KALINOWSKI wrote:

On 17/05/2019 11:31, mick crane wrote:

well that seems to work
"git clone myserver:/path_to_git_repository"
whereas
"git remote add origin myserver:/path_to_git_repository"
fatal: not a git repository (or any of the parent directories): .git



That's because git remote add is meant to add a remote to an existing
git (local) repository. You're probably running it on an empty
directory, so it complains (correctly) that you're not in a repository.


Oh I see, thought message was about the other end.
thanks
--
Key ID4BFEBB31



Re: FW: knockd package long-standing bug

2019-05-17 Thread Brian
On Wed 15 May 2019 at 08:02:01 +, Riccardo Paolo Bestetti wrote:

> -Original Message-
> From: to...@tuxteam.de  
> Sent: mercoledì 15 maggio 2019 07:47
> To: debian-user@lists.debian.org
> Subject: Re: FW: knockd package long-standing bug
> 
> Hi Tomás,
> 
> > I don't understand to whom you sent a mail: to the maintainer's
> > (Leonardo's) Debian address or to the bug tracker? Perhaps you might
> > try to send a mail directly to the maintainer?
> 
> Both. First to the bug tracker, and then last Tuesday to Leonardo's
> Debian address.
> 
> > The second one seems "softer", I'd try that first.
> 
> Sounds good. I'm gonna look into that. Thanks!

You could also consider just applying the patches which work for you
and getting on with life. Bugs have been reported and not responded
to. You have done your part; now it is up to someone else who is in a
position to do something about it. Note that the Package Salvaging
process "..is only intended for actively taking over maintainership."
How an ordinary user would start the process doesn't appear to be
documented.

-- 
Brian.



Re: Install backport during netinstall installation process

2019-05-17 Thread Brian
On Thu 16 May 2019 at 14:01:43 +0100, Rory Campbell-Lange wrote:

[...]

> Consequently I'd be grateful to know if:
> 
> * it is possible to somehow install the backport kernel and dependencies
>   during the netinstall process 
>   (apt-get install doesn't seem available on the virtual terminals)

You could consider preseeding the installation with a late_command to
add backports to sources.list and update and install with apt-get.
This wouldn't suit you, but it can be adapted:

d-i preseed/late_command string 
\  
mkdir /target/media/ARCHIVE-9;  
\  
mount --bind /hd-media /target/media/ARCHIVE-9; 
\  
sed -i 's/^/#/' /target/etc/apt/sources.list;   
\  
echo "deb [ trusted=yes ] file:/media/ARCHIVE-9/debian jessie main contrib" 
>> /target/etc/apt/sources.list;   
\   
   
in-target apt-get update;   
\  
in-target apt-get -y install mc gpm vim bash-completion less;

-- 
Brian.



Re: buildd and buildbot

2019-05-17 Thread Gene Heskett
On Friday 17 May 2019 12:26:56 pm to...@tuxteam.de wrote:

> On Fri, May 17, 2019 at 10:27:47AM -0400, Gene Heskett wrote:
>
> [...]
>
> > Turns out the install only left out two of those, so they are now
> > installed. I assume I need to setup a jail someplace, so whats next?
>
> I'm pretty pressed on time ATM (half a tutorial lying around), so
> for the next couple of days you're on your own (perhaps someone else
> chimes in). I'll pick that up again early next week, unless I am
> superseded in the meantime.
>
> Cheers
> -- t

I have now duplicated this same set of downloads and installs on the 
rock64, including git cloneing linuxcnc, so unless someone jumps in, 
I'll be waiting on you.  I've also installed gitk and git-gui, which 
looks like a good tool to keep my local repo up to date with.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: buildd and buildbot

2019-05-17 Thread tomas
On Fri, May 17, 2019 at 10:27:47AM -0400, Gene Heskett wrote:

[...]

> Turns out the install only left out two of those, so they are now 
> installed. I assume I need to setup a jail someplace, so whats next?  

I'm pretty pressed on time ATM (half a tutorial lying around), so
for the next couple of days you're on your own (perhaps someone else
chimes in). I'll pick that up again early next week, unless I am
superseded in the meantime.

Cheers
-- t


signature.asc
Description: Digital signature


Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread tomas
On Fri, May 17, 2019 at 11:52:02AM -0400, rhkra...@gmail.com wrote:

[...]

> Does putting software on GitHub give them any kind of claim on the 
> intellectual property of the software?

Absolutely not. *If* there's a strategy behind that (there might be, to
the tune of $7.5B), it has to be more subtle.

I've seen quite a few people confusing Git and Github (yes, software
developers). That kind of thing.

Cheers
-- t


signature.asc
Description: Digital signature


Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Dominik George
>Does putting software on GitHub give them any kind of claim on the 
>intellectual property of the software?

No.



Re: Install backport during netinstall installation process

2019-05-17 Thread Curt
On 2019-05-17, Rory Campbell-Lange  wrote:
>> 
>> I'm sure someone here can offer you the exact details of how to do that.
>
> Thanks again for the advice.
>
> I'm pretty sure dpkg isn't available in /target but I didn't try a
> chroot so maybe I'll give that another go!

Well, it's what seems to happening here, for example:

https://wiki.debian.org/DebianInstaller/MultipathSupport

 switch to the second VT using CTRL-ALT-F2.
 copy the patched grub to /target/tmp
 chroot /target dpkg -i /tmp/grub_*.deb
 switch back to the first VT using CTRL-ALT-F1 and continue with the 
installation.

 

> Many thanks
> Rory
>
>


-- 
“When he was dry, he believed it was alcohol he needed, but when he had a few
drinks in him, he knew it was something else, possibly a woman; and when he had
it all — cash, booze, and a wife — he couldn’t be distracted from the great
emptiness that was always falling through him and never hit the ground.” – 
Denis Johnson



Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread rhkramer
On Friday, May 17, 2019 03:28:51 AM Dominik George wrote:
> >> please do*never*  use GitHub for free software
> >
> >Please explain, in detail, why.
> 
> If discrimination against parts of the community is not enough for you,
> here's why:
> 
> https://mako.cc/writing/hill-free_tools.html
> 
> https://www.adamhyde.net/another-good-reason-not-to-use-github/
> 
> https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm

I might try to read these later, but don't have time at the moment, but I do 
have a question:

Does putting software on GitHub give them any kind of claim on the 
intellectual property of the software?



Re: Perl does not support utime with nanosecond resolution

2019-05-17 Thread Sven Joachim
On 2019-05-17 15:44 +0200, Steve Keller wrote:

> The Perl module Time::HiRes in Debian stretch does support nanosecond
> resolution for stat() but not for utime(), although Linux has the
> utimensat() system call providing that function.
>
> $ cat /etc/debian_version
> 9.9
> $ perl -e "use Time::HiRes qw(stat);"
> $ perl -e "use Time::HiRes qw(utime);"
> "utime" is not exported by the Time::HiRes module
> Can't continue after import errors at 
> /usr/lib/x86_64-linux-gnu/perl/5.24/Time/HiRes.pm line 68.
> BEGIN failed--compilation aborted at -e line 1.
> $
>
> BTW, Ubuntu 18.04, with perl 5.26, supports this:
>
> $ cat /etc/debian_version
> buster/sid
> $ perl -e "use Time::HiRes qw(stat);"
> $ perl -e "use Time::HiRes qw(utime);"
> $
>
> What's the reason for this

Stretch has only perl 5.24, and apparently utime support in Time::HiRes
was added after that.

> and can I enable utime() with nanosecond
> support in Debian stretch?

You would probably have to install a newer version of Time::HiRes from
CPAN[1].

Cheers,
   Sven


1. https://metacpan.org/pod/Time::HiRes



Re: using git locally

2019-05-17 Thread Jude DaShiell
This comes from David Karl Oliver who is no longer among the living.
Marine: Muscles are required intelligence not expected.  His cousin
joined the Corps too and David Oliver and me worked as civilians for the
Navy in the same office.

On Fri, 17 May 2019, Eduardo M KALINOWSKI wrote:

> Date: Fri, 17 May 2019 10:59:36
> From: Eduardo M KALINOWSKI 
> To: debian-user@lists.debian.org
> Subject: Re: using git locally
> Resent-Date: Fri, 17 May 2019 14:59:53 + (UTC)
> Resent-From: debian-user@lists.debian.org
>
> On 17/05/2019 11:31, mick crane wrote:
> > well that seems to work
> > "git clone myserver:/path_to_git_repository"
> > whereas
> > "git remote add origin myserver:/path_to_git_repository"
> > fatal: not a git repository (or any of the parent directories): .git
> >
> > probably I can worry about that later at least I know now I can talk
> > to it.
>
> That's because git remote add is meant to add a remote to an existing
> git (local) repository. You're probably running it on an empty
> directory, so it complains (correctly) that you're not in a repository.
>
> If you really must, do "git init ." and then "git remote add". But just
> use clone to create the local repository based on another repository.
>
>

-- 



Re: OT: Newbie friendly C++ list

2019-05-17 Thread Brad Rogers
On Fri, 17 May 2019 10:50:52 -0400
rhkra...@gmail.com wrote:

Hello rhkra...@gmail.com,

>of those real time messaging type things where you post a question and

That's IRC.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Kill joy, bad guy, big talking, small fry
Death On Two Legs - Queen


pgpm9wLMoPscZ.pgp
Description: OpenPGP digital signature


Re: OT: Newbie friendly C++ list

2019-05-17 Thread Dan Purgert
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

rhkra...@gmail.com wrote:
> Background: I've never fully (or even mostly / sufficiently) grokked C
> or C++, but now I'm in the position of having (or at least wanting) to
> review (and, ideally, modify) a large program written in C++
> (scintilla / scite).
>
> Question: I would like to find one (or a small number) of "newbie
> friendly" email lists where I could ask various questions.  

Dunno about mailing lists, but the usenet groups comp.lang.c and
comp.lang.c++ have put up with my noob questions -- provided that I at
least show some effort of trying to get the thing.

And even though you don't prefer them, there are IRC chatrooms focused
on the topic(e.g. ##programming on freenode)

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAlze0e4ACgkQjhHd8xJ5
ooE6rgf/WLfDrzyE0SqY7IcDjA/BhMiepH5NVc9yEBWFf4s3hLQ2Ymgjt7O7lloa
lGxd8Mgog5XQGe/VsOukt4DZNHIiXngY6DGlJmaZaq1/+D4+rzc4zORf5xFecjL5
RCNwTB0ZtVteHInJfVUDGVN2d4CgvhThqX5svYDDULYipo2yRq7PkjG93rW4aWdh
0OqYDC+PuxsRzNFcU7n0V9Tw9utNxJhYGf11y+AJo4Bcc+1fk/5c10B06MQXvxAX
ItiC/ktQxSVK1lhoXhKe4RN8vMDaltE8d9LLaiD7vKL56b/SR7Il9apEJcPxiX+A
Feppg9glplVB68jbBYnfBVTQkwpVaw==
=MB9y
-END PGP SIGNATURE-

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281



Re: using git locally

2019-05-17 Thread mick crane

On 2019-05-17 15:05, Brad Rogers wrote:

On Fri, 17 May 2019 14:36:36 +0100



thanks
--
Key ID4BFEBB31



Re: Install backport during netinstall installation process

2019-05-17 Thread Rory Campbell-Lange
On 17/05/19, Curt (cu...@free.fr) wrote:
> On 2019-05-17, Rory Campbell-Lange  wrote:
> > On 16/05/19, Curt (cu...@free.fr) wrote:
> >> On 2019-05-16, Rory Campbell-Lange  wrote:
> >> >
> >> > * it is possible to somehow install the backport kernel and dependencies
> >> >   during the netinstall process 
> >> >   (apt-get install doesn't seem available on the virtual terminals)
> >> 
> >> I guess preseeding is one way of doing it (gleaned from a rapid internet
> >> search):
> >> 
> >> https://blog.raymond.burkholder.net/index.php?/archives/899-Debian-Preseed-Backport-Kernel.html
> >
> > That is very helpful, Curt. Thanks a lot.
> 
> All the experts are on vacation, apparently, but I think a
> less-involved, feasible method would be to use the netinstall iso
> normally but after grub installation (and *before reboot*), from a
> virtual terminal, 'chroot' into /target and install the backported
> kernel deb manually with 'dpkg -i' (you could mount a thumb drive
> containing the downloaded kernel or wget the kernel from the appropriate
> repository).
> 
> I'm sure someone here can offer you the exact details of how to do that.

Thanks again for the advice.

I'm pretty sure dpkg isn't available in /target but I didn't try a
chroot so maybe I'll give that another go!

Many thanks
Rory



Re: using git locally

2019-05-17 Thread Eduardo M KALINOWSKI
On 17/05/2019 11:31, mick crane wrote:
> well that seems to work
> "git clone myserver:/path_to_git_repository"
> whereas
> "git remote add origin myserver:/path_to_git_repository"
> fatal: not a git repository (or any of the parent directories): .git
>
> probably I can worry about that later at least I know now I can talk
> to it. 

That's because git remote add is meant to add a remote to an existing
git (local) repository. You're probably running it on an empty
directory, so it complains (correctly) that you're not in a repository.

If you really must, do "git init ." and then "git remote add". But just
use clone to create the local repository based on another repository.

-- 
The Marines:
The few, the proud, the not very bright.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br



OT: Newbie friendly C++ list

2019-05-17 Thread rhkramer
Background: I've never fully (or even mostly / sufficiently) grokked C or C++, 
but now I'm in the position of having (or at least wanting) to review (and, 
ideally, modify) a large program written in C++ (scintilla / scite).

Question: I would like to find one (or a small number) of "newbie friendly" 
email lists where I could ask various questions.  

Aside: I much prefer a mail list to a forum or a, hmm what't the word -- one 
of those real time messaging type things where you post a question and the 
people that are online at the time see the question and might answer it.  I 
have and will occasionally continue to use those, but I like mail lists best.

(Aside: because debian-user is a list that I try to pay attention to, and 
often get answers even to OT questions, I may pose some of the questions 
here.)

Thanks!!



Re: using git locally

2019-05-17 Thread mick crane

On 2019-05-17 14:56, Greg Wooledge wrote:



If you really *did* create a git repository on a remote server, and
you want to clone it onto your local PC, you use a "git clone" command.

Something like:  git clone my.server:/whatever.git


well that seems to work
"git clone myserver:/path_to_git_repository"
whereas
"git remote add origin myserver:/path_to_git_repository"
fatal: not a git repository (or any of the parent directories): .git

probably I can worry about that later at least I know now I can talk to 
it.


mick
--
Key ID4BFEBB31



Re: buildd and buildbot

2019-05-17 Thread Gene Heskett
On Friday 17 May 2019 04:29:04 am to...@tuxteam.de wrote:

> On Fri, May 17, 2019 at 03:30:45AM -0400, Gene Heskett wrote:
> > Greetings folks;
> >
> > Thinking of building a local copy of a project with a cross compiler
> > to make rpi (armhf) stuffs on this amd64 box, I installed buildd and
> > buildbot and some usefull looking friends yesterday, and in about 2
> > hours lost the usb services totally, twice having to reboot with the
> > reset button.
>
> This is a bit like trying to peel an egg with an excavator [1].
> Whereas possible in principle, it'll take some skill.
>
> There are several ways to skin that cat, but whenever your build
> machine's kernel is not too far away from your target's,
> dpkg-buildpackage, debootstrap and schroot are your friends.
all installed
> This is a list of the packages you might need for cross-building a
> package (assuming the package authors have done their stuff right)
>
>   - schroot
already installed
> This is a (somewhat friendlier) chroot wrapper. You do your
> build in a chroot: your target architecture's build is going
> to want packages which possibly conflict with your installed
> ones (yes, there's multiarch, so you can have ARM libc installed
> side by side with AMD64 libc, but some packages (Gtk, I'm
> looking at you!) are not multi-arch capable.
>
>   - debootstrap
already installed
> Installs a "base" Debian system in the (above) chroot (this will
> be an ARM Debian in your case)
>
>   - binfmt-misc
part of another binfmt-deb installed
> This is a little nasty thing which looks at a binary and
> says "oh, this looks like ARM: let's call qemu on it". Kinda
> like the shebang line thingy on steroids.
>
>   - qemu-user-static
already installed
> Somehow the ARM stuff in your (build) chroot has to be run.
> That's qemu's part. Note that the schroot wrapper has facilities
> to map the "right" emulator (via a bind-mount) into the chroot.
>
> A recommended package would be an apt cache, since you'll be
> building up many base systems with debootstrap to just tear them
> down. Downloading all those packages time and again gets boring
> soon (unless your Internet connection is faster than your disk,
> that is). Apt-cacher-ng seems a good choice.
ng version now installed>
> Alternatively there are pbuilder (aka "personal builder") and
> 
sbuild,
already installed.
> from which I'd totally start with pbuilder, which is 
> easier for quick and dirty jobs. Sbuild is more "official"
> (let's call it the "pro" version), so if you become a Debian
> developer, you should know this one too. But basically they do
> the process outlined above, chroot and all. I have the impression
> one has to understand the process beneath that anyway.
[...]
>
> Hope that gets you started.
>
> Cheers
> -- t
Turns out the install only left out two of those, so they are now 
installed. I assume I need to setup a jail someplace, so whats next?  

Thank you Tomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: using git locally

2019-05-17 Thread Brad Rogers
On Fri, 17 May 2019 14:36:36 +0100
mick crane  wrote:

Hello mick,

>Is it ssh:// that is wrong or I've failed to get the syntax right for 
>git ?

I'm no expert on git, so ask me questions - I probably won't be able to
answer them anyway.   :-)

That said, this might help:-

https://stackoverflow.com/questions/28827831/how-to-setup-git-on-local-network

The relevant part appears to be:

-Quote---
Basically, you'll want to use git daemon. If you just need to set up a
single repository, that's one line from each machine:

Server:

git daemon --base-path=/path/to/repo --export-all

Client:

git remote add LocalServerName git:///

where  is some reference to that machine (IPv4, IPv6,
.local, etc.). You can also specify --verbose for the daemon command for
more detailed output.

I think, also, you could have --base-path point to a folder with many
repositories, and that would let you specify which project you wanted on
the client-side like so:

git daemon --base-path=/path/to/all/repos

git remote add ServerName git:///MyProject/

Be advised: using --export-all will let any computer on the network pull
from your repo.

---End Quote-

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Everything in life should be free, except the bits that belong to me
Selfish Rubbish - Public Image Ltd


pgpPqGNN7tiWx.pgp
Description: OpenPGP digital signature


Perl does not support utime with nanosecond resolution

2019-05-17 Thread Steve Keller
The Perl module Time::HiRes in Debian stretch does support nanosecond
resolution for stat() but not for utime(), although Linux has the
utimensat() system call providing that function.

$ cat /etc/debian_version
9.9
$ perl -e "use Time::HiRes qw(stat);"
$ perl -e "use Time::HiRes qw(utime);"
"utime" is not exported by the Time::HiRes module
Can't continue after import errors at 
/usr/lib/x86_64-linux-gnu/perl/5.24/Time/HiRes.pm line 68.
BEGIN failed--compilation aborted at -e line 1.
$

BTW, Ubuntu 18.04, with perl 5.26, supports this:

$ cat /etc/debian_version
buster/sid
$ perl -e "use Time::HiRes qw(stat);"
$ perl -e "use Time::HiRes qw(utime);"
$

What's the reason for this and can I enable utime() with nanosecond
support in Debian stretch?

Steve



Re: using git locally

2019-05-17 Thread Greg Wooledge
On Fri, May 17, 2019 at 02:36:36PM +0100, mick crane wrote:
> Because I am always making mistakes I thought, if it's not too hard, to see
> about using git locally.

If that is literally all you want to do, then you don't need to set up
a "repository".  You have your project, sitting in a directory.  You can
turn that directory into a git-managed directory and use "git commit"
and so on right inside it, without ever pushing or pulling or remoteing
or origining or any other stuff where your directory is linked to some
outside entity.

> I made a git repository for project following destructions
> https://www.digitalocean.com/community/tutorials/how-to-use-git-effectively
> but I'm having bother accessing it remotely.

Digital ocean is not exactly the first choice here.

The official Git documentation, in particular chapter 4


would probably be a better starting point.

> I can ssh from one pc to another using keys with key phrase.
> "ssh mick@server"
> but
> "git remote add origin ssh://mick@server/home/mick/git/camera"
> and many variations I get.

If you really *did* create a git repository on a remote server, and
you want to clone it onto your local PC, you use a "git clone" command.

Something like:  git clone my.server:/whatever.git



Re: Screenshots of Debian software

2019-05-17 Thread Gene Heskett
On Friday 17 May 2019 07:57:21 am Curt wrote:

> On 2019-05-17, Gene Heskett  wrote:
> >> It's very easy to upload screenshots to screenshots.debian.net.
> >> Possibly less work than organising them in a git repository. I just
> >> did one to test and it took seconds
> >> (http://screenshots.debian.net/package/crispy-doom)
> >
> > Nice idea, but "no screenshot available" when I sent ff to look.
>
> Ditto (no screenshot available).
>
> Maybe it has to be "moderated" before it appears, so we won't stumble
> on Phyllis Diller in the buff or something.
>
> ;-)
>
> > Cheers, Gene Heskett

Now you are telling your age Curt. She's been gone for a while, but I can 
remember when I thought she looked pretty good despite her "fright wig" 
which was her own hair.  But that was all part of her "shtick".

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



using git locally

2019-05-17 Thread mick crane

hello,
Because I am always making mistakes I thought, if it's not too hard, to 
see about using git locally.

I made a git repository for project following destructions
https://www.digitalocean.com/community/tutorials/how-to-use-git-effectively
but I'm having bother accessing it remotely.
I can ssh from one pc to another using keys with key phrase.
"ssh mick@server"
but
"git remote add origin ssh://mick@server/home/mick/git/camera"
and many variations I get.
fatal: not a git repository (or any of the parent directories): .git
I'm not really understanding the difference between "ssh" and "ssh://" 
except "ssh" works in terminal and "ssh://" doesn't.
Is it ssh:// that is wrong or I've failed to get the syntax right for 
git ?

mick
--
Key ID4BFEBB31



Re: Salsa vs Github

2019-05-17 Thread Nate Bargmann
* On 2019 17 May 04:53 -0500, john doe wrote:
 
> I could be missing something here but why not simply 'mirroring' the
> github repo to salsa?

That is possible but, as far as I know, it is a manual process.  I do
the same with a project hosted on both SourceForge and GitHub.  For any
updates I manually push to each repository to keep them in sync.

Features of each site are not reflected on the other.  These are things
like issue trackers, pull requests generated through the respective
sites, or forks on the respective sites.  These things are all
peripheral to the source in the Git repository but are important
metadata which the Git repository will not contain.

When branches are created that are intended to be long lived, they must
be pushed to each site individually.  Sometimes mistakes happen so one
almost needs a checklist to be sure are the steps get done each time.

HTH,

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: http://www.n0nb.us  GPG key: D55A8819  GitHub: N0NB


signature.asc
Description: PGP signature


Re: Screenshots of Debian software

2019-05-17 Thread Curt
On 2019-05-17, Gene Heskett  wrote:
>>
>> It's very easy to upload screenshots to screenshots.debian.net.
>> Possibly less work than organising them in a git repository. I just
>> did one to test and it took seconds
>> (http://screenshots.debian.net/package/crispy-doom)
>
> Nice idea, but "no screenshot available" when I sent ff to look.

So I select "without" (a screenshot) and fall upon a million libs.

 Question: How do you take a screenshot of a lib?
 Answer:   You normally don't, that's why they're missing.

I looked at 'About':

 Everybody (sic)* can take screenshots and upload them. Our admin team will just
 review your changes before they become publicly visible.

So Dowland's shot of Phyllis is doubtless under review.

> Cheers, Gene Heskett

* Everybody probably can't, but anybody can.




Readme sanity check

2019-05-17 Thread Paul Sutton
Hi

I have tried to put some instructions as to how to use the levels for
rocksndiamonds stored at.

https://salsa.debian.org/zleap-guest/rocksndiamondslevels

README.md

Hopefully I have explained this in such a way that it allows people to
create their own levels, but also test the levels that I have created by
copying them in to the right location.  Would it be possible to someone
have a read through, proof read & sanity check the instructions to
ensure they make sense and I am not writing too much please.

Please feel free to either comment here, or issue a merge request with
edited instructions ( I need to get more used to handling merge requests
anyway)

Thanks

Paul


-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D
Hi



Re: Screenshots of Debian software

2019-05-17 Thread Curt
On 2019-05-17, Gene Heskett  wrote:
>>
>> It's very easy to upload screenshots to screenshots.debian.net.
>> Possibly less work than organising them in a git repository. I just
>> did one to test and it took seconds
>> (http://screenshots.debian.net/package/crispy-doom)
>
> Nice idea, but "no screenshot available" when I sent ff to look.

Ditto (no screenshot available).

Maybe it has to be "moderated" before it appears, so we won't stumble on 
Phyllis Diller in the buff or something.

;-)

> Cheers, Gene Heskett





Re: buildd and buildbot

2019-05-17 Thread Gene Heskett
On Friday 17 May 2019 04:29:04 am to...@tuxteam.de wrote:

> On Fri, May 17, 2019 at 03:30:45AM -0400, Gene Heskett wrote:
> > Greetings folks;
> >
> > Thinking of building a local copy of a project with a cross compiler
> > to make rpi (armhf) stuffs on this amd64 box, I installed buildd and
> > buildbot and some usefull looking friends yesterday, and in about 2
> > hours lost the usb services totally, twice having to reboot with the
> > reset button.
>
> This is a bit like trying to peel an egg with an excavator [1].
> Whereas possible in principle, it'll take some skill.
>
> There are several ways to skin that cat, but whenever your build
> machine's kernel is not too far away from your target's,
> dpkg-buildpackage, debootstrap and schroot are your friends.
>
> This is a list of the packages you might need for cross-building a
> package (assuming the package authors have done their stuff right)
>
>   - schroot
> This is a (somewhat friendlier) chroot wrapper. You do your
> build in a chroot: your target architecture's build is going
> to want packages which possibly conflict with your installed
> ones (yes, there's multiarch, so you can have ARM libc installed
> side by side with AMD64 libc, but some packages (Gtk, I'm
> looking at you!) are not multi-arch capable.
>
>   - debootstrap
> Installs a "base" Debian system in the (above) chroot (this will
> be an ARM Debian in your case)
>
>   - binfmt-misc
> This is a little nasty thing which looks at a binary and
> says "oh, this looks like ARM: let's call qemu on it". Kinda
> like the shebang line thingy on steroids.
>
>   - qemu-user-static
> Somehow the ARM stuff in your (build) chroot has to be run.
> That's qemu's part. Note that the schroot wrapper has facilities
> to map the "right" emulator (via a bind-mount) into the chroot.
>
> A recommended package would be an apt cache, since you'll be
> building up many base systems with debootstrap to just tear them
> down. Downloading all those packages time and again gets boring
> soon (unless your Internet connection is faster than your disk,
> that is). Apt-cacher-ng seems a good choice.
>
> Alternatively there are pbuilder (aka "personal builder") and
> sbuild, from which I'd totally start with pbuilder, which is
> easier for quick and dirty jobs. Sbuild is more "official"
> (let's call it the "pro" version), so if you become a Debian
> developer, you should know this one too. But basically they do
> the process outlined above, chroot and all. I have the impression
> one has to understand the process beneath that anyway.
>
> Buildd is the automatic machinery Debian uses to (re-)build
> packages as new versions arrive, so that is again one floor
> above sbuild.
>
> Hope that gets you started.
>
> Cheers
> -- t

Many thanks Tomas, I hadn't figured it would be that complex, and after 
yesterdays experience with buildbot and buildd, a bit more "wary". 
buildd I think needs to be run in a jail with leak detectors. Valgrind?

Printed FFR, thanks again.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: Screenshots of Debian software

2019-05-17 Thread Gene Heskett
On Friday 17 May 2019 05:36:32 am Jonathan Dowland wrote:

> On Thu, May 16, 2019 at 03:40:20PM +0100, Paul Sutton wrote:
> >Looking at https://screenshots.debian.net/  the Debian project seems
> > to want some screen shots of different applications etc.
> >
> >I have taken some screenshots for various purposes and since seeing
> > this have started to rename, organize  and keep them in case the are
> > useful for this part of the project.
> >
> >These are currently stored on Salsa at
> >
> >https://salsa.debian.org/zleap-guest/screenshots
> >
> >Is anyone here, on the team that deals with screenshots please,  I am
> >probably far better at taking the screenshots, renaming them etc and
> >uploading them to salsa,  where I am happy for someone to download
> > them and upload to the screenshot repository as required.  please
> > use which ever license is appropriate.
>
> In this reply I am copying Christoph Haas, who originally set up the
> Screenshots project, and also the Debian Games Team, who have made
> heavy use of it in the past. Perhaps someone will be interested in
> exploring moving your screenshots into the screenshots.debian.net
> collection.
>
> However, at the moment, you have in your collection only pictures for
> brasero, devede, libreoffice, and rocksndiamonds, all of which have
> screenshots on screenshots.debian.net already. So it's unlikely anyone
> will spare the time to ferry these particular ones over.
>
> >If we need a volunteer to do the uploading to the above site, I am
> > _not_ offering to volunteer as I am trying to do other things
> > relating to the project.
>
> It's very easy to upload screenshots to screenshots.debian.net.
> Possibly less work than organising them in a git repository. I just
> did one to test and it took seconds
> (http://screenshots.debian.net/package/crispy-doom)

Nice idea, but "no screenshot available" when I sent ff to look.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: Screenshots of Debian software

2019-05-17 Thread Paul Sutton



On 17/05/2019 10:36, Jonathan Dowland wrote:
> On Thu, May 16, 2019 at 03:40:20PM +0100, Paul Sutton wrote:
>> Looking at https://screenshots.debian.net/  the Debian project seems to
>> want some screen shots of different applications etc.
>>
>> I have taken some screenshots for various purposes and since seeing this
>> have started to rename, organize  and keep them in case the are useful
>> for this part of the project.
>>
>> These are currently stored on Salsa at
>>
>> https://salsa.debian.org/zleap-guest/screenshots
>>
>> Is anyone here, on the team that deals with screenshots please,  I am
>> probably far better at taking the screenshots, renaming them etc and
>> uploading them to salsa,  where I am happy for someone to download them
>> and upload to the screenshot repository as required.  please use which
>> ever license is appropriate.
> 
> In this reply I am copying Christoph Haas, who originally set up the
> Screenshots project, and also the Debian Games Team, who have made heavy
> use of it in the past. Perhaps someone will be interested in exploring
> moving your screenshots into the screenshots.debian.net collection.
> 
> However, at the moment, you have in your collection only pictures for
> brasero, devede, libreoffice, and rocksndiamonds, all of which have
> screenshots on screenshots.debian.net already. So it's unlikely anyone
> will spare the time to ferry these particular ones over.
> 
>> If we need a volunteer to do the uploading to the above site, I am _not_
>> offering to volunteer as I am trying to do other things relating to the
>> project.
> 
> It's very easy to upload screenshots to screenshots.debian.net. Possibly
> less work than organising them in a git repository. I just did one to
> test and it took seconds
> (http://screenshots.debian.net/package/crispy-doom)
> 
> 
Hi

Thanks for this, I have cc'd Christoph Haas and the games team in to
this too.

I will be creating more screenshots and will add them to my repository
and they are then open to be used generally.

I will also look at what we are short of and see if I can help in that
respect too.

Paul





-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Re: Salsa vs Github

2019-05-17 Thread john doe
On 5/17/2019 11:47 AM, Paul Sutton wrote:
>
>
> On 17/05/2019 10:23, Jonathan Dowland wrote:
>> On Thu, May 16, 2019 at 04:51:22PM +0100, Paul Sutton wrote:
>>> is it possible to
>>> 1. Fork a project between github -> salsa or between salsa -> github ?
>>
>> No. But, you can create a corresponding project in one based on the same
>> git repository. I.e., you clone the git repository from one project,
>> create the second project on the other platform, and push the git repo's
>> references (branches and tags) to the new project. Neither project will
>> be "aware" of the copy on the other platform.
>>
>> Those who have answered "Yes, they are both git repositories" are
>> ignoring that the issues, pull requests and relationship-tracking
>> between a project and a fork within the same platform are not stored in
>> the git repository.
>>
>>> 2 As above but issue pull / merge requests between the two?
>>
>> No.
>>
>>> I am asking this, as if someone has github, and can do the above they
>>> are able to perhaps help, without having to sign up to an account on
>>> salsa.
>>
>> If you create a project on GitHub which is effectively a "mirror" of
>> your project on Salsa, you (or scripts/services you set up to do so on
>> your behalf) will need to make sure to update the GitHub project with
>> changes to the Salsa one, and vice-versa, and also monitor issues and
>> pull requests raised on GitHub.
>>
>> It's a trade-off between this work (a burden on you) and the burden of
>> potential contributors having to sign up for a Salsa account. But if you
>> don't want to put off contributors, then you can choose to shoulder that
>> burden :)
>>
> Cool thanks,  most of my github projects are personal anyway. It is
> probably just quicker to, as you said,  create and clone a new
> repository, add the files to it,then push it up to salsa.
>
> I won't be doing anything complex like tracking issues between the two
> platforms just yet as I am still learning how to do the basics.
>

I could be missing something here but why not simply 'mirroring' the
github repo to salsa?

--
John Doe



Re: Salsa vs Github

2019-05-17 Thread Paul Sutton



On 17/05/2019 10:23, Jonathan Dowland wrote:
> On Thu, May 16, 2019 at 04:51:22PM +0100, Paul Sutton wrote:
>> is it possible to
>> 1. Fork a project between github -> salsa or between salsa -> github ?
> 
> No. But, you can create a corresponding project in one based on the same
> git repository. I.e., you clone the git repository from one project,
> create the second project on the other platform, and push the git repo's
> references (branches and tags) to the new project. Neither project will
> be "aware" of the copy on the other platform.
> 
> Those who have answered "Yes, they are both git repositories" are
> ignoring that the issues, pull requests and relationship-tracking
> between a project and a fork within the same platform are not stored in
> the git repository.
> 
>> 2 As above but issue pull / merge requests between the two?
> 
> No.
> 
>> I am asking this, as if someone has github, and can do the above they
>> are able to perhaps help, without having to sign up to an account on
>> salsa.
> 
> If you create a project on GitHub which is effectively a "mirror" of
> your project on Salsa, you (or scripts/services you set up to do so on
> your behalf) will need to make sure to update the GitHub project with
> changes to the Salsa one, and vice-versa, and also monitor issues and
> pull requests raised on GitHub.
> 
> It's a trade-off between this work (a burden on you) and the burden of
> potential contributors having to sign up for a Salsa account. But if you
> don't want to put off contributors, then you can choose to shoulder that
> burden :)
> 
Cool thanks,  most of my github projects are personal anyway. It is
probably just quicker to, as you said,  create and clone a new
repository, add the files to it,then push it up to salsa.

I won't be doing anything complex like tracking issues between the two
platforms just yet as I am still learning how to do the basics.

Paul

-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Re: Screenshots of Debian software

2019-05-17 Thread Jonathan Dowland

On Thu, May 16, 2019 at 03:40:20PM +0100, Paul Sutton wrote:

Looking at https://screenshots.debian.net/  the Debian project seems to
want some screen shots of different applications etc.

I have taken some screenshots for various purposes and since seeing this
have started to rename, organize  and keep them in case the are useful
for this part of the project.

These are currently stored on Salsa at

https://salsa.debian.org/zleap-guest/screenshots

Is anyone here, on the team that deals with screenshots please,  I am
probably far better at taking the screenshots, renaming them etc and
uploading them to salsa,  where I am happy for someone to download them
and upload to the screenshot repository as required.  please use which
ever license is appropriate.


In this reply I am copying Christoph Haas, who originally set up the
Screenshots project, and also the Debian Games Team, who have made heavy
use of it in the past. Perhaps someone will be interested in exploring
moving your screenshots into the screenshots.debian.net collection.

However, at the moment, you have in your collection only pictures for
brasero, devede, libreoffice, and rocksndiamonds, all of which have
screenshots on screenshots.debian.net already. So it's unlikely anyone
will spare the time to ferry these particular ones over.


If we need a volunteer to do the uploading to the above site, I am _not_
offering to volunteer as I am trying to do other things relating to the
project.


It's very easy to upload screenshots to screenshots.debian.net. Possibly
less work than organising them in a git repository. I just did one to
test and it took seconds (http://screenshots.debian.net/package/crispy-doom)


--
👱🏻  Jonathan Dowland
✎j...@debian.org
🔗   https://jmtd.net



Re: Salsa vs Github

2019-05-17 Thread Jonathan Dowland

On Thu, May 16, 2019 at 04:51:22PM +0100, Paul Sutton wrote:

is it possible to
1. Fork a project between github -> salsa or between salsa -> github ?


No. But, you can create a corresponding project in one based on the same
git repository. I.e., you clone the git repository from one project,
create the second project on the other platform, and push the git repo's
references (branches and tags) to the new project. Neither project will
be "aware" of the copy on the other platform.

Those who have answered "Yes, they are both git repositories" are
ignoring that the issues, pull requests and relationship-tracking
between a project and a fork within the same platform are not stored in
the git repository.


2 As above but issue pull / merge requests between the two?


No.


I am asking this, as if someone has github, and can do the above they
are able to perhaps help, without having to sign up to an account on salsa.


If you create a project on GitHub which is effectively a "mirror" of
your project on Salsa, you (or scripts/services you set up to do so on
your behalf) will need to make sure to update the GitHub project with
changes to the Salsa one, and vice-versa, and also monitor issues and
pull requests raised on GitHub.

It's a trade-off between this work (a burden on you) and the burden of
potential contributors having to sign up for a Salsa account. But if you
don't want to put off contributors, then you can choose to shoulder that
burden :)

--
👱🏻  Jonathan Dowland
✎   j...@dow.land
🔗   https://jmtd.net



Re: Install backport during netinstall installation process

2019-05-17 Thread Curt
On 2019-05-17, Rory Campbell-Lange  wrote:
> On 16/05/19, Curt (cu...@free.fr) wrote:
>> On 2019-05-16, Rory Campbell-Lange  wrote:
>> >
>> > Consequently I'd be grateful to know if:
>> >
>> > * it is possible to somehow install the backport kernel and dependencies
>> >   during the netinstall process 
>> >   (apt-get install doesn't seem available on the virtual terminals)
>> 
>> I guess preseeding is one way of doing it (gleaned from a rapid internet
>> search):
>> 
>> https://blog.raymond.burkholder.net/index.php?/archives/899-Debian-Preseed-Backport-Kernel.html
>
> That is very helpful, Curt. Thanks a lot.

All the experts are on vacation, apparently, but I think a
less-involved, feasible method would be to use the netinstall iso
normally but after grub installation (and *before reboot*), from a
virtual terminal, 'chroot' into /target and install the backported
kernel deb manually with 'dpkg -i' (you could mount a thumb drive
containing the downloaded kernel or wget the kernel from the appropriate
repository).

I'm sure someone here can offer you the exact details of how to do that.

Good luck.

> Apart from the link you've kindly pointed me to, there is also an
> ancient but still pertinent-seeming post here about using preseed files
> with netboot:
> https://www.credativ.com/credativ-blog/2010/07/howto-debian-preseed-with-netboot
>
> Also the manual at 
> https://www.debian.org/releases/stretch/amd64/apbs02.html.en
> suggests one can provide a preseed.cfg file via tftp, e.g.
>
>   preseed/url=tftp://host/path/to/preseed.cfg
>   preseed/url/checksum=5da499872becccfeda2c4872f9171c3d
>
> I'll give that a go.
>
> Thanks a lot!
> Rory
>
>


-- 
“When he was dry, he believed it was alcohol he needed, but when he had a few
drinks in him, he knew it was something else, possibly a woman; and when he had
it all — cash, booze, and a wife — he couldn’t be distracted from the great
emptiness that was always falling through him and never hit the ground.” – 
Denis Johnson



Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Paul Sutton



On 17/05/2019 09:39, to...@tuxteam.de wrote:
> On Fri, May 17, 2019 at 09:28:51AM +0200, Dominik George wrote:
 please do*never*  use GitHub for free software
> 
> [links]
> 
> Thanks for the links. Up to now, I avoided Github mainly because
> I'm always wary of those "open core", which pay lip service to
> "Open Source" (and make heavy use of free software) while taking
> advantage of the network effect to keep users captive.
> 
> After Microsoft's "kiss of death" they're doubly-suspect to me.
> 
> But it's always good to have some links by smarter people than
> me...
> 
> Cheers
> -- t
> 


I agree that if we stick to either using salsa for Debian projects it
makes it easier to collaborate, keeps everything together and Debian ,
as hosts, keeps interests at heart, accountability is then to the
community.  Similarly if we self host a repository structure then we are
in control,

As the underpinning idea allows us to collaborate cross platforms then
we have the choice.

Paul

-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread tomas
On Fri, May 17, 2019 at 09:28:51AM +0200, Dominik George wrote:
> >> please do*never*  use GitHub for free software

[links]

Thanks for the links. Up to now, I avoided Github mainly because
I'm always wary of those "open core", which pay lip service to
"Open Source" (and make heavy use of free software) while taking
advantage of the network effect to keep users captive.

After Microsoft's "kiss of death" they're doubly-suspect to me.

But it's always good to have some links by smarter people than
me...

Cheers
-- t


signature.asc
Description: Digital signature


Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Mark Allums

On 5/17/19 2:28 AM, Dominik George wrote:

please do*never*  use GitHub for free software


Please explain, in detail, why.


If discrimination against parts of the community is not enough for you, here's 
why:

https://mako.cc/writing/hill-free_tools.html

https://www.adamhyde.net/another-good-reason-not-to-use-github/

https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm

-nik



I'm not convinced,  Give me more.

Mark



Re: buildd and buildbot

2019-05-17 Thread tomas
On Fri, May 17, 2019 at 03:30:45AM -0400, Gene Heskett wrote:
> Greetings folks;
> 
> Thinking of building a local copy of a project with a cross compiler to 
> make rpi (armhf) stuffs on this amd64 box, I installed buildd and 
> buildbot and some usefull looking friends yesterday, and in about 2 
> hours lost the usb services totally, twice having to reboot with the 
> reset button.

This is a bit like trying to peel an egg with an excavator [1]. Whereas
possible in principle, it'll take some skill.

There are several ways to skin that cat, but whenever your build
machine's kernel is not too far away from your target's, dpkg-buildpackage,
debootstrap and schroot are your friends.

This is a list of the packages you might need for cross-building a
package (assuming the package authors have done their stuff right)

  - schroot
This is a (somewhat friendlier) chroot wrapper. You do your
build in a chroot: your target architecture's build is going
to want packages which possibly conflict with your installed
ones (yes, there's multiarch, so you can have ARM libc installed
side by side with AMD64 libc, but some packages (Gtk, I'm
looking at you!) are not multi-arch capable.

  - debootstrap
Installs a "base" Debian system in the (above) chroot (this will
be an ARM Debian in your case)

  - binfmt-misc
This is a little nasty thing which looks at a binary and
says "oh, this looks like ARM: let's call qemu on it". Kinda
like the shebang line thingy on steroids.

  - qemu-user-static
Somehow the ARM stuff in your (build) chroot has to be run.
That's qemu's part. Note that the schroot wrapper has facilities
to map the "right" emulator (via a bind-mount) into the chroot.

A recommended package would be an apt cache, since you'll be
building up many base systems with debootstrap to just tear them
down. Downloading all those packages time and again gets boring
soon (unless your Internet connection is faster than your disk,
that is). Apt-cacher-ng seems a good choice.

Alternatively there are pbuilder (aka "personal builder") and
sbuild, from which I'd totally start with pbuilder, which is
easier for quick and dirty jobs. Sbuild is more "official"
(let's call it the "pro" version), so if you become a Debian
developer, you should know this one too. But basically they do
the process outlined above, chroot and all. I have the impression
one has to understand the process beneath that anyway.

Buildd is the automatic machinery Debian uses to (re-)build
packages as new versions arrive, so that is again one floor
above sbuild.

Hope that gets you started.

Cheers
-- t


signature.asc
Description: Digital signature


Re: please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Dominik George
>> please do*never*  use GitHub for free software
>
>Please explain, in detail, why.

If discrimination against parts of the community is not enough for you, here's 
why:

https://mako.cc/writing/hill-free_tools.html

https://www.adamhyde.net/another-good-reason-not-to-use-github/

https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm

-nik



buildd and buildbot

2019-05-17 Thread Gene Heskett
Greetings folks;

Thinking of building a local copy of a project with a cross compiler to 
make rpi (armhf) stuffs on this amd64 box, I installed buildd and 
buildbot and some usefull looking friends yesterday, and in about 2 
hours lost the usb services totally, twice having to reboot with the 
reset button.

Neither were configured to actually do anything yet. buildd expressed its 
displeasure in the logs frequently because cron was launching it when It 
had not been given anything to do.

So I removed them both about 21:00 last night and the machine is I think 
stable again.  Relatively new stretch install.  So users might be aware 
that the stuff isn't up the the usual stability standards one has come 
to expect of debian.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



Re: Age Ranges for contributors was: Salsa vs Github

2019-05-17 Thread Paul Sutton



On 16/05/2019 20:58, Nate Bargmann wrote:
> A bit of searching shows that some international legislation seems to be
> responsible for the age restrictions.
> 
> This project cites the GDPR:
> 
> https://github.com/hypothesis/product-backlog/issues/561
> 
> GitHub's ToS says an account holder must be at least 13 and gives US law
> as the reason in section B(3):
> 
> https://help.github.com/en/articles/github-terms-of-service
> 
> And finally, is GitHub's statement on child labor giving UK law as one
> of the reasons:
> 
> https://help.github.com/en/articles/github-statement-against-modern-slavery-and-child-labor
> 
> Of course, IANAL, etc., but the last two links do shed some light on the
> issue for me after a quick glance.
> 
> - Nate
> 
I can fully understand the reasoning behind all this.

Lets just carry on as we are doing,  Our code of conduct covers
everything, helps keep people safe and links to mechanisms to report
inappropriate contact.

I will see at some point if I can help put together some information
for non techy people who work with different age groups (well contribute
to this) due to lack of engagement from the community safety team, it is
less priority now.  I will ask at the e-safety seminar in a few weeks.
As  to me if practitioners are able to support young people we benefit
from this.

Thank you to everyone for their help on this issue,

Paul





-- 
Paul Sutton
http://www.zleap.net
https://www.linkedin.com/in/zleap/
gnupg : 7D6D B682 F351 8D08 1893  1E16 F086 5537 D066 302D



Re: Install backport during netinstall installation process

2019-05-17 Thread Rory Campbell-Lange
On 16/05/19, Curt (cu...@free.fr) wrote:
> On 2019-05-16, Rory Campbell-Lange  wrote:
> >
> > Consequently I'd be grateful to know if:
> >
> > * it is possible to somehow install the backport kernel and dependencies
> >   during the netinstall process 
> >   (apt-get install doesn't seem available on the virtual terminals)
> 
> I guess preseeding is one way of doing it (gleaned from a rapid internet
> search):
> 
> https://blog.raymond.burkholder.net/index.php?/archives/899-Debian-Preseed-Backport-Kernel.html

That is very helpful, Curt. Thanks a lot.

Apart from the link you've kindly pointed me to, there is also an
ancient but still pertinent-seeming post here about using preseed files
with netboot:
https://www.credativ.com/credativ-blog/2010/07/howto-debian-preseed-with-netboot

Also the manual at https://www.debian.org/releases/stretch/amd64/apbs02.html.en
suggests one can provide a preseed.cfg file via tftp, e.g.

  preseed/url=tftp://host/path/to/preseed.cfg
  preseed/url/checksum=5da499872becccfeda2c4872f9171c3d

I'll give that a go.

Thanks a lot!
Rory



please do *never* use GitHub for free software, was Re: Salsa vs Github

2019-05-17 Thread Mark Allums

On 5/16/19 11:34 AM, Dominik George wrote:

please do*never*  use GitHub for free software


Please explain, in detail, why.

Mark