Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Mathias Behrle]

* W. Martin Borgert: " Re: Sorce only uploads with sbuild (was: Bits from the
  Release Team)" (Tue, 23 Jul 2019 17:30:22 +0200):

> Quoting Sean Whitton :
> > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
> > (easier) `dgit push-source`.  
> 
> I prefer to build only once, if possible, generating both binary and
> source .changes. Both in a clean chroot. Then I can try out my .debs
> and on success just sign and dput. 

That's exactly my use case, too.
Also I am building in parallel backports uploaded to a different mirror
(reprepro), where the (cleanly built) binaries are needed.


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Debian and our frenemies of containers and userland repos

[Johannes Schauer]

Quoting Marc Haber (2019-07-24 08:17:19)
> On Mon, 22 Jul 2019 12:38:36 +0200, "Enrico Weigelt, metux IT consult"
>  wrote:
> >Containerization is a valid approach for some kind of workloads
> >(eg. specific inhouse applications) that can be easily isolated from
> >the rest. But it comes with the price of huge redundancies (depending
> >on how huge some application stacks are). And unless everybody wants
> >to go back of maintaining everything on his own, we still need distros.
> 
> Compared to a full VM, a container _is_ smaller. I am not sure whether
> the difference is as huge in times where we have kernel same-page
> merging though.

You can create really small Debian chroots with mmdebstrap. In contrast to
debootstrap, you can create chroots with just all Essential:yes packages and
their dependencies (debootstrap cannot do less than Priority:required):

   $ mmdebstrap --variant=essential unstable debian-unstable.tar

and you can use the dpkg path-excluded feature to remove lots of stuff you
might not need inside a container:

   $ mmdebstrap --variant=essential \
   --dpkgopt='path-exclude=/usr/share/man/*' \
   --dpkgopt='path-include=/usr/share/man/man[1-9]/*' \
   --dpkgopt='path-exclude=/usr/share/locale/*' \
   --dpkgopt='path-include=/usr/share/locale/locale.alias' \
   --dpkgopt='path-exclude=/usr/share/doc/*' \
   --dpkgopt='path-include=/usr/share/doc/*/copyright' \
   --dpkgopt='path-include=/usr/share/doc/*/changelog.Debian.*' \
   unstable debian-unstable.tar

or even with less than the Essential:yes package set but busybox instead:

   $ mmdebstrap --variant=custom \
   --include=dpkg,busybox,libc-bin,base-files,base-passwd,debianutils \
   --setup-hook='mkdir -p "\$1/bin"' \
   --setup-hook='for p in awk cat chmod chown cp diff echo env grep less ln 
mkdir mount rm rmdir sed sh sleep sort touch uname; do ln -s busybox 
"\$1/bin/\$p"; done' \
   --setup-hook='echo root:x:0:0:root:/root:/bin/sh > "\$1/etc/passwd"' \
   --setup-hook='printf "root:x:0:\nmail:x:8:\nutmp:x:43:\n" > 
"\$1/etc/group"' \
   unstable debian-unstable.tar

Thanks!

cheers, josch



signature.asc
Description: signature

Re: Debian and our frenemies of containers and userland repos

[Johannes Schauer]

Quoting Marc Haber (2019-07-24 08:17:19)
> Do we have a build technology that uses containers instead of chroots yet?

Either using any container-based autopkgtest backend (like lxc or lxd):

$ sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=lxc

Or using the built-in "unshare" backend which uses linux user namespaces:

$ sbuild --chroot-mode=unshare --chroot=debian-unstable.tar

The latter allows one to either directly specify a chroot tarball with the
--chroot argument or will look inside ~/.cache/sbuild for a fitting chroot
tarball.

If you also build your chroot tarballs using a tool that doesn't require
superuser privileges like mmdebstrap (or debootstrap with the patch from
#829134) then you can essentially build arbitrary packages inside arbitrary
chroots without ever becoming root or touching anything outside your home
directory, given that you at some point did "sysctl -w
kernel.unprivileged_userns_clone=1" until #898446 is fixed.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Debian and our frenemies of containers and userland repos

[Ansgar]

Marc Haber writes:
> Compared to a full VM, a container _is_ smaller. I am not sure whether
> the difference is as huge in times where we have kernel same-page
> merging though.
>
> Do we have a build technology that uses containers instead of chroots
> yet?

I haven't used it so far, but at least "whalebuilder" exists.

The gitlab-ci used on salsa.d.o also uses Docker containers; people also
build packages using this (mostly for testing though, see for example [1]).

Ansgar

  [1] https://salsa.debian.org/salsa-ci-team/pipeline

Re: Debian and our frenemies of containers and userland repos

[Marc Haber]

On Mon, 22 Jul 2019 12:38:36 +0200, "Enrico Weigelt, metux IT consult"
 wrote:
>Containerization is a valid approach for some kind of workloads
>(eg. specific inhouse applications) that can be easily isolated from
>the rest. But it comes with the price of huge redundancies (depending
>on how huge some application stacks are). And unless everybody wants
>to go back of maintaining everything on his own, we still need distros.

Compared to a full VM, a container _is_ smaller. I am not sure whether
the difference is as huge in times where we have kernel same-page
merging though.

Do we have a build technology that uses containers instead of chroots
yet?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Bug#932769: [moreinfo] DoS via DHCP request

[Sven Hartge]

On Tue, 23 Jul 2019 19:32:04 -0600 Mark Hutchison
 wrote:

> When I look at systemctl for the dhclient service, I can see that there's
> an error, "can't create /var/lib/dhcp/dhclient.intname.leases Read Only
> file system", and then the DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
> starts every few seconds, and occasionally the service will show "RTNETLINK
> answers: File Exists."
> 
> I'm guessing from the error that dhclient has a problem with not being able
> to read / write to the client leases file, declines the IP and requests
> another, but secretly holds on to the IP.

> I see that someone reported this similar bug back in 2018 as well, I think
> they may be the same thing.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209
> 
> Thanks, just let me know if you have any questions.

To confirm your findings: We saw the same as well with isc-dhcp-client.
As soon as the filesystem its lease file resides on becomes unreachable
or read-only, it throws a fit and just hammers away at the DHCP
infrastructure.

In our case every client has a fixed DHCP reservation and only ever gets
OFFERed the same IP, which he then declines, but when you have several
hundred clients flooding DHCP reequests at the same time, the load on
the infrastructure, including switches with DHCP Snooping active, is
immense.

I also think that #888209 is the same issue.

Coincidentally it also happened in out VMware cluster when an
iSCSI-backed LUN when down but you should be easily able to reproduce
this with a simple local KVM setup.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Re: Bug#932769: #932769

[Marc Haber]

On Tue, 23 Jul 2019 19:34:11 -0600, Mark Hutchison
 wrote:
>I'm guessing from the error that dhclient has a problem with not being able
>to read / write to the client leases file, declines the IP and requests
>another, but secretly holds on to the IP.

I'd like to be able to assign this bug to a package so that we know
where to hunt for the issue.

Can you, maybe, confirm that you're actually using the
isc-dhcp-client, and then install a minimal system, with no desktop
environment, no network manager, no automated network init. Then,
without network active, force the filesystem into read-only and invoke
the DHCP client in debug mode from the console.

If your hypothesis is correct, this should also show the faulty
behavior. That would be a solid point from where we can take a closer 
look.

A next step would be to see whether this behavior also happens when
the file system is mounted read-only manually, taking the complex
VM/iSCSI aspect from the setup.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

tag2upload (git-debpush) service architecture - draft

[Ian Jackson]

Hi all.

I wrote this draft design doc / deployment plan for the tag-to-upload
service, perhaps best summarised by Sean like this:

  We designed and implemented a system to make it possible for DDs to
  upload new versions of packages by simply pushing a specially
  formatted git tag to salsa.

  Please see this blog post to learn about how it works:
  https://spwhitton.name/blog/entry/tag2upload/

The server side of this is not running yet and there is some work to
do for that.

We've had a number of peripheral conversations, and informal
internal reviews, but I think it's the stage now to have a public
design review etc.  I'm CCing this to -devel because I just did a
lightning talk demo of the prototype and IME many people are
interested in these kinds of questions.

Right now this document is maintained here:
   https://salsa.debian.org/dgit-team/dgit/tree/wip.tag2upl-draft
but NB that that is a potentially rewinding branch.  (I probably won't
rewind it until it's time to fold it into master at which point I may
just delete it.)

Ian.


TAG-TO-UPLOAD - DEBIAN - DRAFT DESIGN / DEPLOYMENT PLAN
===

Overall structure and dataflow
--

 * Uploader (DD or DM) makes signed git tag (containing metadata
   forming instructions to tag2upload service)

 * Uploader pushes said tag to salsa. [1]

 * salsa sends webhook to tag2upload service.

 * tag2upload service
: provides an HTTPS service accessible to salsa's IP addrs
: fishes url and tag name out of webhook json
! checks that url is basically sane
- retrieves tag data (git shallow clone)
! parses the tag metadata
! checks to see if it is relevant
! verifies signature
! checks to see if signed by DD, or DM for appropriate package
- obtains relevant git history
- obtains, if applicable, orig tarball from archive
- makes source package
# signs source package and "dgit view" git tag
- pushes history and both tags to dgit git server
- uploads source package to archive

 * archive publishes package as normal

[1] In principle other git servers would be possible but it would have
to be restricted to ones where we can either avoid, or stop, them
being used as a channel for a DoS attack against the tag2upload
service.

Service architecture


I propose the following architecture for the tag2upload service.

 * Packet filter limiting the incoming connections to salsa.

 * Conventional webserver offering TLS and using Let's Encrypt.
   (Alternatively, HTTP could be used, but in the future we
   might want to handle embargoed security uploads so let's not.)

 * Web-service-style "application server" written in some scripting
   language listens on a local TCP port, handles HTTP connections
   proxied by the webserver, parses the JSON, and connects to:

 * Trusted service daemon.  Listens on a TCP connection and accepts a
   simple line-based "url tag" protocol.  Checks urls and tags for
   basic syntax and sanity (eg that it has the right protocol and
   host).  Keeps track of incoming requests in a sqlite3 database so
   that execution can be deferred and retried as applicable.  Spawns
   per-request worker children.

 * Request processor.  Trusted.  Does the trusted parts above.

 * Some VM or container or maybe chroot.  Instantiated by request
   processor via adt-virt protocol.  Request processor controls this
   by sending it commands (via the adt-virt facility for this).

 * In the VM, git is used to fetch all the bits and dgit does the
   actual source package generation work.

 * Trusted service daemon needs access to its GPG key which should be
   on a hardware token and not accessible to the VM instances.

Privsep
---

The tag2upload service will have to have a signing key that can upload
source packages to the archive.

We do not want that signing key to be abused.  In particular, even
though it will be in a hardware token we want to avoid giving
unrestricted access to that key to code which also has a large attack
surface.  In particular, source package construction is very complex.

So there will be a privilege separation arrangement, as described
above.  Different tasks run in a different security context:

! is fully trusted and has access to the signing key

- runs in the discardable VM or container, controlled by `!'

# is achieved by the `dgit rpush' protocol, where the trusted
  (invoking, signing) part offers a restricted signing oracle to
  the less-trusted (building) part.  The signing oracle will check
  that the files to be signed are roughly in the right form and
  that they name the right source package.  It will construct the
  "dgit view" git tag itself from metadata provided by the
  building part.

: can run as different unix users or even different VMs or
  something, if desirable

Reproducibility, metdata and auditing
---

Bug#932769: #932769

[Mark Hutchison]

Hi fellas,

Apologies for the brevity in the initial bug report.  I was using the
reportbug tool directly from the console of the VM I was working on, small
resolution.  Allow me to elaborate...

We initially discovered this bug testing our storage product, we had a
Debian 10 VM running in a typical ESXi 6.7 environment with iSCSI backed
storage.  The VM ran in a VMDK file on a VMFS datastore volume.  While the
VM was running in memory, we removed the storage initiators from ESXi
purposefully to test something unrelated, to simulate a storage outage.
After a couple of minutes the OS will go into R/O mode without its disk,
and at that time dhclient will rapidly request IP's from our ISC DHCP
server.  dhclient will take the IP, consume it from the DHCP pool and then
request another.  After some period of time this depletes the DHCP pool,
several hours to days depending on the scopes size.  This could also be
replicated by deleting the hard disk from a running VM in a virtual
environment.

When I look at systemctl for the dhclient service, I can see that there's
an error, "can't create /var/lib/dhcp/dhclient.intname.leases Read Only
file system", and then the DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
starts every few seconds, and occasionally the service will show "RTNETLINK
answers: File Exists."

I'm guessing from the error that dhclient has a problem with not being able
to read / write to the client leases file, declines the IP and requests
another, but secretly holds on to the IP.

The DHCP server logs will show a final DHCPDECLINE after the ACK, and mark
the address as abandoned.  The VM will still have the address leased
however.  After a period of time VMware's guest tools will show all the
consumed IP's belonging to that MAC address and virtual interface.  Network
gear ARP shows the IP's belonging to the same MAC as well.

We've consistently reproduced this bug in our lab, and performed the test
simultaneously with a Debian 9, Centos and Ubuntu 16 instance to make sure
it wasn't some kind of NetworkManager thing, or a broader Linux issue.

I see that someone reported this similar bug back in 2018 as well, I think
they may be the same thing.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209

Thanks, just let me know if you have any questions.

Bug#932769: [moreinfo] DoS via DHCP request

[Mark Hutchison]

Hi fellas,

Apologies for the brevity in the initial bug report.  I was using the
reportbug tool directly from the console of the VM I was working on, small
resolution.  Allow me to elaborate...

We initially discovered this bug testing our storage product, we had a
Debian 10 VM running in a typical ESXi 6.7 environment with iSCSI backed
storage.  The VM ran in a VMDK file on a VMFS datastore volume.  While the
VM was running in memory, we removed the storage initiators from ESXi
purposefully to test something unrelated, to simulate a storage outage.
After a couple of minutes the OS will go into R/O mode without its disk,
and at that time dhclient will rapidly request IP's from our ISC DHCP
server.  dhclient will take the IP, consume it from the DHCP pool and then
request another.  After some period of time this depletes the DHCP pool,
several hours to days depending on the scopes size.  This could also be
replicated by deleting the hard disk from a running VM in a virtual
environment.

When I look at systemctl for the dhclient service, I can see that there's
an error, "can't create /var/lib/dhcp/dhclient.intname.leases Read Only
file system", and then the DHCPREQUEST > DHCPACK > DHCPDECLINE sequence
starts every few seconds, and occasionally the service will show "RTNETLINK
answers: File Exists."

I'm guessing from the error that dhclient has a problem with not being able
to read / write to the client leases file, declines the IP and requests
another, but secretly holds on to the IP.

The DHCP server logs will show a final DHCPDECLINE after the ACK, and mark
the address as abandoned.  The VM will still have the address leased
however.  After a period of time VMware's guest tools will show all the
consumed IP's belonging to that MAC address and virtual interface.  Network
gear ARP shows the IP's belonging to the same MAC as well.

We've consistently reproduced this bug in our lab, and performed the test
simultaneously with a Debian 9, Centos and Ubuntu 16 instance to make sure
it wasn't some kind of NetworkManager thing, or a broader Linux issue.

I see that someone reported this similar bug back in 2018 as well, I think
they may be the same thing.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888209

Thanks, just let me know if you have any questions.



On Tue, Jul 23, 2019 at 4:23 PM Tomáš Pospíšek  wrote:

> Am 23.07.19 um 17:57 schrieb Ben Hutchings:
> > On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
> >> Package: general
> >> Followup-For: Bug #932769
> >>
> >> Could you privide a recipe on how to reproduce this? There's a lot of
> >> very special setup below, that someone wwould need large amounts of time
> >> to reporoduce I feel.
> >>
> >> Is it possible to reduce the problem to something easily demonstratable?
> >>
> >> This seems to be an important issue to me.
> >>
> >> I think the problem here *might* be a kernel problem? Re-assign this to
> >> kernel package?
> > [...]
> >
> > So far as I know, the kernel only ever does DHCP if you net-boot
> > without an initramfs.
>
> My focus was more on this issue here - aparenty:
>
> Mark Hutchison wrote:
>
> >> This DoS's the server [due to DHCP changing IPs rapidly
> >> - my interpretation] and the interface attempts to take and discard
> >> IP's in a rapid fashion.
>
> -> changing IPs of an interface of a *VM* can DoS the server. Which I
> think is not expected, and not terribly funny. It takes a bit of not so
> straightforward circumstances (as far as I can understand the bug
> report), but then an attacker can DoS the server via DHCP. Which is uh,
> I mean ah, um.
>
> Information is a bit sparse here, though.
>
> If I may shoot completely off topic for a second: Woah, many thanks
> for your terrific kernel maintenance work Ben. Truly amazing :-o!!!
> Thanks so may times a lot! Woah :-) Thank you! (this doesn't exclude
> the rest of the kernel team - my thanks extend to you all - it's just
> that I have the honor to say thanks to a participating party in this
> email exchange 8v)!
> *t
>

Re: merged-/usr-via-symlinks damage control (was Re: usrmerge -- plan B?)

[Guillem Jover]

On Sun, 2019-02-24 at 03:23:09 +0100, Guillem Jover wrote:
> On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote:
[…]
> >   - file a bug on base-installer to request an option to install
> > non-broken systems due to merged-/usr-via-symlinks.
> 
> Done. 

This got a patch from Colin Watson (thanks!), but it never got applied
before the release, :( I think the commit description does not fully
reflect the current situation and problems, but I'd take that patch as
is any day.

Doing an installation w/o the broken deployment is not too difficult
though, as long as you know what needs doing:

  - Select expert mode.
  - Do all the steps, until installing the base system.
  - Spawn a shell:
+ Edit /var/lib/dpkg/info/bootstrap-base.posinst,
+ Add --no-merged-usr to the debootstrap call.
  - Proceed with the installation.


In addition this deployment method also breaks:

  - dlocate.
  - apt-file.
  - packages.debian.org's search.
  - find /lib (or any of the other symlinked directories).
  - …

> > And I'm probably going to end up writing a unmerge-usr-via-symlinks
> > script so that people with damaged systems can go back somewhat to a
> > sane state, and to open the possibility for a fully automated migration
> > to a proper and correct merged-/usr w/o all the problems above.
> 
> And I might need to start on this soon enough. :(

I'm not sure I can be bothered TBH.

> In addition, given that most probably Debian buster will end up
> installing broken systems by default. I might end up also looking into
> generating fixed minimal netinst images or mini netboot images with a
> fixed debootstrap, or I guess just cdebootstrap present which has
> sane behavior. But I would definitely not be able host the artifacts
> for those. :/

So this happened in buster, but as per the above, one can "easily" avoid
the breakage, if you know about it. :/

Thanks,
Guillem

Bug#932769: [moreinfo] DoS via DHCP request

[Tomáš Pospíšek]

Am 23.07.19 um 17:57 schrieb Ben Hutchings:
> On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
>> Package: general
>> Followup-For: Bug #932769
>>
>> Could you privide a recipe on how to reproduce this? There's a lot of
>> very special setup below, that someone wwould need large amounts of time
>> to reporoduce I feel.
>>
>> Is it possible to reduce the problem to something easily demonstratable?
>>
>> This seems to be an important issue to me.
>>
>> I think the problem here *might* be a kernel problem? Re-assign this to
>> kernel package?
> [...]
> 
> So far as I know, the kernel only ever does DHCP if you net-boot
> without an initramfs.

My focus was more on this issue here - aparenty:

Mark Hutchison wrote:

>> This DoS's the server [due to DHCP changing IPs rapidly
>> - my interpretation] and the interface attempts to take and discard
>> IP's in a rapid fashion.

-> changing IPs of an interface of a *VM* can DoS the server. Which I
think is not expected, and not terribly funny. It takes a bit of not so
straightforward circumstances (as far as I can understand the bug
report), but then an attacker can DoS the server via DHCP. Which is uh,
I mean ah, um.

Information is a bit sparse here, though.

If I may shoot completely off topic for a second: Woah, many thanks
for your terrific kernel maintenance work Ben. Truly amazing :-o!!!
Thanks so may times a lot! Woah :-) Thank you! (this doesn't exclude
the rest of the kernel team - my thanks extend to you all - it's just
that I have the honor to say thanks to a participating party in this
email exchange 8v)!
*t

Bug#931296: general: Camera flash drive mount does not show up on desktop

[Tomas Pospisek]

Package: general
Followup-For: Bug #931296

Hi Roger,

Roger wrote:

> Plugging in camera in Buster does not show flash storage on desktop as
> it did in previous versions with Xfce DE.

There was no reply to this bug report. The problem is, that debugging
this involves some work, which you need to do. Such as going through
the logs on your machine and trying to see whether there's some
interesting info there related to the problem you are seeing.

Also googling around if you find some reports about this problem on the
net might be useful.

Without that info this bug report will have to be closed, since
there's not much we can do.
*t

Bug#932769: [moreinfo] DoS via DHCP request

[Ben Hutchings]

On Tue, 2019-07-23 at 16:51 -0400, Tomas Pospisek wrote:
> Package: general
> Followup-For: Bug #932769
> 
> Could you privide a recipe on how to reproduce this? There's a lot of
> very special setup below, that someone wwould need large amounts of time
> to reporoduce I feel.
> 
> Is it possible to reduce the problem to something easily demonstratable?
> 
> This seems to be an important issue to me.
> 
> I think the problem here *might* be a kernel problem? Re-assign this to
> kernel package?
[...]

So far as I know, the kernel only ever does DHCP if you net-boot
without an initramfs.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?




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

Re: Comparing/Using Conda with Debian

[Tomas Pospisek]

Am 11.07.19 um 06:53 schrieb Steffen Möller:

> On an project-internal mailing list the thread "Conda vs Debian"
> [etc.]

What's Conda?
*t

Re: Notes on packaging PCYNLITX

[Tomas Pospisek]

Hi,

I have a few rather higher level questions about PCYNLITX.

* are there any known users of PCYNLITX, in the sense of, does
  there exist an application, that actually uses PCYNLITX?

* I have read through the web page of PCYNLITX. I can not
  make up my mind. The web page is talking about how well
  documented PCYNLITX is, but there's no code examples of
  how PCYNLITX is used, as far as I could find. Without
  that it's too hard for me to make up my mind about it.
  I find the concept interesting, but without seeing
  code - hmmm...

?
*t

Am 12.07.19 um 08:52 schrieb Bagas Sanjaya:
> Hello,
> 
> I've filed RFP for PCYNLITX sometimes ago [1]:
> 
> In PCYNLITX download page [2], it can be installed by using installation 
> script. However, after examining install
> script, I noticed following:
> - PCYNLITX doesn't employ version numbering like any other project/packages. 
> It would be difficult to identify
> which is the latest version. So I use version number 0.0~git20190606 in RFP 
> report.
> - The script install wxWidgets library from third-party repository, not from 
> Debian. It use codelite repo (for Stretch):
>> apt-add-repository 'deb http://repos.codelite.org/wx3.0.4/debian/
>> stretch libs'
> - Evince will be installed as runtime dependency, possibly for documentation. 
> For non-GNOME users (KDE, XFCE, etc.)
> which use different readers (like Okular and Atril) this can bloat their 
> system and become unnecessary.
> - All steps are performed using sudo. If the script is run by root user, this 
> will be redundant, since the installation
> is done by root privileges.
> 
> If I will packaging PCYNLITX for Debian, any suggestions, assuming that I 
> have read New Maintainers Guideline and
> related Debian packaging documentation?
> 
> Cheers, Bagas
> 
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931400
> [2]: http://www.pcynlitx.tech/the-installation-of-pcynlitx/
> 
> -- 
> An old man doll... just what I always wanted! - Clara
> 

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

One more question. When you say VNWare integrated product. AFAIK vmware 
have their own networking module in the kernel? Can you reproduce this 
with some other virtualisation technology like kvm, qemu?


And one more question: do depending on who does the DHCP receival in the 
VM (systemd? isc-dhcp-client? [...]?): shouldn't there be some rate 
limiting sanity check in the DHCP client?

*t

On Tue, 23 Jul 2019, Tomas Pospisek wrote:


Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t


To: Debian Bug Tracking System 
Subject: general: DHCP request bug when storage lost
Date: Mon, 22 Jul 2019 14:48:00 -0600

Package: general
Severity: important
Tags: l10n

Dear Maintainer,

While doing unrelated storage testing for our VMware integrated product, we 
purposefully recreated
a storage outage by removing the iSCSI initiators from the backing array 
hosting the vmdk disk
images for the virtual machine.

Upon removal of uplinks to storage, the VM goes into a R/O file system state 
after 5-10 minutes.
When storage initiators are brought back up and the LUNs are rescanned, the VM 
begins to
rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server in 
a way due
to the number of DHCPDECLINE errors, and the interface attempts to take and 
discard IP's in a
rapid fashion.

This only seems to appear on this distribution, and I can't replicate the 
behavior on Debian 9
or in a desktop environment.



-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled






-- System Information:
Debian Release: 10.0
 APT prefers stable
 APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#932769: [moreinfo] DoS via DHCP request

[Tomas Pospisek]

Package: general
Followup-For: Bug #932769

Could you privide a recipe on how to reproduce this? There's a lot of
very special setup below, that someone wwould need large amounts of time
to reporoduce I feel.

Is it possible to reduce the problem to something easily demonstratable?

This seems to be an important issue to me.

I think the problem here *might* be a kernel problem? Re-assign this to
kernel package?

When you say that it DoS'es the server then what does "top" say? What is
being DoS'ed? Is it the CPU?
*t

It would be truly cool, if you could provide more infos.
*t

> To: Debian Bug Tracking System 
> Subject: general: DHCP request bug when storage lost
> Date: Mon, 22 Jul 2019 14:48:00 -0600
> 
> Package: general
> Severity: important
> Tags: l10n
> 
> Dear Maintainer,
> 
> While doing unrelated storage testing for our VMware integrated product, we 
> purposefully recreated
> a storage outage by removing the iSCSI initiators from the backing array 
> hosting the vmdk disk 
> images for the virtual machine.
> 
> Upon removal of uplinks to storage, the VM goes into a R/O file system state 
> after 5-10 minutes.
> When storage initiators are brought back up and the LUNs are rescanned, the 
> VM begins to 
> rapidly request DHCP leases from an ISC DHCP server.  This DoS's the server 
> in a way due
> to the number of DHCPDECLINE errors, and the interface attempts to take and 
> discard IP's in a
> rapid fashion. 
> 
> This only seems to appear on this distribution, and I can't replicate the 
> behavior on Debian 9
> or in a desktop environment.
> 
> 
> 
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled





-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#932836: ITP: golang-rsc-pdf -- PDF reader library

[Emanuel Krivoy]

Package: wnpp
Severity: wishlist
Owner: Emanuel Krivoy 

* Package name: golang-rsc-pdf
  Version : 0.1.0+git20180525.c47d69c-1
  Upstream Author : Russ Cox
* URL : https://github.com/rsc/pdf
* License : BSD-3-clause
  Programming Lang: Go
  Description : Golang library that provides a reader for the PDF format

PDF is Adobe's Portable Document Format. A PDF document is a complex data format
built on a fairly simple structure. This package exposes the simple structure
along with some wrappers to extract basic information. If more complex
information is needed, it is possible to extract that information by
interpreting the structure exposed by this package.

This library is a dependency of the golang.org/x/arch library, which is a
dependency of delve (github.com/go-delve/delve, ITP in #932835). If possible I'd
like this package to be co-mantained/sponsored by the Go Team.

Bug#932835: ITP: delve -- Delve is a debugger for the Go programming language.

[Emanuel Krivoy]

Package: wnpp
Severity: wishlist
Owner: Emanuel Krivoy 

* Package name: delve
  Version : 1.2.0+git20190509.c30a333-1
  Upstream Author : Derek Parker 
* URL : https://github.com/go-delve/delve
* License : MIT
  Programming Lang: Go
  Description : Delve is a debugger for the Go programming language.

The goal of the project is to provide a simple, full featured debugging tool
for Go. Delve should be easy to invoke and easy to use. Chances are if you're
using a debugger, things aren't going your way. With that in mind, Delve
should stay out of your way as much as possible.

Delve is the recommended debugging tool in official documentation
(https://golang.org/doc/gdb) and blog
(https://blog.golang.org/debugging-what-you-deploy).

If possible I'd like this package to be co-mantained/sponsored by the Go Team.

Re: Help needed with a script generating a .deb (Done. Now what?)

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 08:31:34PM +0200, dettus wrote:
> Now that I am able to create packages What do I do with them?
Read my link again.
Also, the packaging help list is debian-mentors@.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help needed with a script generating a .deb (Done. Now what?)

[dettus]

Hello.


So, I succeeded!

There are two Warnings left

W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt

If you do not mind, I would like to keep them. Now that I am able to
create packages What do I do with them?


Thomas


On 7/23/19 7:22 PM, Andrey Rahmatullin wrote:

On Tue, Jul 23, 2019 at 07:19:32PM +0200, dettus wrote:

Running it ends with  the following feedback:




dpkg-buildpackage: info: full upload (original source is included)
Now running lintian...
W: dmagnetic: missing-depends-line
W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: spelling-error-in-description allows to allows one to
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
W: dmagnetic: manpage-has-errors-from-man
usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined
W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
Finished running lintian.
Now signing changes and any dsc files...
  signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
gpg: skipped "Thomas Dettbarn ": No secret key
gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No
secret key
debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1045:
running debsign failed
patching file Makefile


Any help with the warnings is appreciated...

You can use lintian-info to read the tag descriptions.

Re: git & Debian packaging sprint report

[Ansgar Burchardt]

Russ Allbery writes:
> Scott Kitterman  writes:
>> Except that we have different requirements than git.  Git isn't looking
>> for security properties from SHA-1, so it's highly likely it'll meet
>> their accident avoidance requirements long after it's no longer
>> appropriate for security related assertions.
>
>> I don't think adding more SHA-1 in a security sensitive context is a
>> good plan.
>
> I talked this over briefly in the security pod at work with some other
> security engineers who know more crypto than I do to sanity-check my
> initial opinion.
>
> The consensus among all of us was that if you have an opportunity to pick
> something other than SHA-1 when designing a new protocol, you should.

We have that opportunity here, so I guess we should then? :-)

There are also other useful properties the current implementation has:
for example the archive contains the artifact that was signed.  This can
be checked at a later time unlike a Git tag on salsa.d.o that may or may
not exist in the future.  It is always possible to go back to the key
that was used to introduce an artifact without having to trust any
system.

> But
> if it's not simple to pick a different hash, SHA-1 preimage resistance is
> reasonable and the other design properties of the system should dominate
> any concern about SHA-1 preimage attacks.

What about MD5's preimage resistance?  We don't really care about
collision attacks after all.

We have most infrastructure already using SHA-2 and there are
preparations to support newer hashes as well; it is a regression to
introduce a new system bound to SHA1 for the foreseeable future (and
given Git's use of SHA1 their need to require a strong hash is far
less).

Ansgar

Re: Sorce only uploads with sbuild

[Russ Allbery]

PICCA Frederic-Emmanuel 
writes:

>> $ origtargz   # since I use pristine-tar

> what is the difference with

> git deborig

I use pristine-tar so that I can get back exactly the same tarball that
upstream uses, so that anyone can verify that the Debian package starts
from the same source using cmp (and so that upstream tarball signatures
will verify).  git deborig looks like it's going to reconstruct a tarball
from Git, which will not produce the identical tarball as upstream's
release.

Opinions differ on whether this matters, but it matters to me, so I'm
still using pristine-tar despite its shortcomings.

>> $ dgit --gbp build
>> $ dgit --gbp push-source

> or dgit --gbp sbuild

Ack, yes, sorry, I meant sbuild and typed it incorrectly.

-- 
Russ Allbery (r...@debian.org)   

RE:Sorce only uploads with sbuild

[PICCA Frederic-Emmanuel]

> $ origtargz   # since I use pristine-tar

what is the difference with

git deborig

> $ dgit --gbp build
> $ dgit --gbp push-source

or dgit --gbp sbuild

to build via sbuild in a clean chroot, 
everythongs setup via propellor indeed thanks to sean and joeyh :))

> Getting started with dgit felt a bit intimidating, but it basically just
> worked once I got sbuild set up (and you've already crossed that hurdle),
> and the payoff in reduced mental load was totally worth it.

+1, my mental load was reduced a lot with dgit
In combination with salsa-ci, the packaging is a lot easier now.
I can not wait for this tag2upload thinks :))

then we just missed a nice tool in order to make mass modifications 
(lintian-brush ?, other project ?)

Cheers

Frederic

Re: Help needed with a script generating a .deb

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 07:19:32PM +0200, dettus wrote:
> Running it ends with  the following feedback:
> 
> 
> 
> 
> dpkg-buildpackage: info: full upload (original source is included)
> Now running lintian...
> W: dmagnetic: missing-depends-line
> W: dmagnetic: description-synopsis-starts-with-article
> W: dmagnetic: spelling-error-in-description allows to allows one to
> W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
> W: dmagnetic: manpage-has-errors-from-man
> usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined
> W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
> Finished running lintian.
> Now signing changes and any dsc files...
>  signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
> gpg: skipped "Thomas Dettbarn ": No secret key
> gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No
> secret key
> debsign: gpg error occurred!  Aborting
> debuild: fatal error at line 1045:
> running debsign failed
> patching file Makefile
> 
> 
> Any help with the warnings is appreciated...
You can use lintian-info to read the tag descriptions.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Help needed with a script generating a .deb

[dettus]

Hello all.


Thanks to your input, I think I am getting closer.
For debian, I created a repository at 
https://github.com/dettus/ports_and_packages/tree/master/Debian



In it, you will find a debian/ subdirectory. In which I put the files 
that seem to be required for

debuild, if I am not mistaken?


You will also find a script called "mkpackage.sh". It takes care of 
downloading the source file

from my website, and creating the .dsc file.

Running it ends with  the following feedback:




dpkg-buildpackage: info: full upload (original source is included)
Now running lintian...
W: dmagnetic: missing-depends-line
W: dmagnetic: description-synopsis-starts-with-article
W: dmagnetic: spelling-error-in-description allows to allows one to
W: dmagnetic: extra-license-file usr/share/doc/dmagnetic/LICENSE.txt
W: dmagnetic: manpage-has-errors-from-man 
usr/share/man/man5/dMagneticini.5.gz 44: warning: macro `RS' not defined

W: dmagnetic: menu-item-creates-new-section Games usr/share/menu/dmagnetic:2
Finished running lintian.
Now signing changes and any dsc files...
 signfile dsc dmagnetic_0.16-1.dsc Thomas Dettbarn 
gpg: skipped "Thomas Dettbarn ": No secret key
gpg: /tmp/debsign.9vHNgUB3/dmagnetic_0.16-1.dsc: clear-sign failed: No 
secret key

debsign: gpg error occurred!  Aborting
debuild: fatal error at line 1045:
running debsign failed
patching file Makefile


Any help with the warnings is appreciated...



Thomas

On 7/23/19 12:26 PM, Ricardo Mones wrote:

Hi Thomas,

On Tue, Jul 23, 2019 at 11:25:40AM +0200, Thomas Dettbarn wrote:

Hello!

So, I have this awesome project, that I am trying to get into the
package repository of Debian. I already filed an RFP, which can be
found at the WNPP bug tracker, where it is gathering dust.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929619

So, I tried my hand at creating a package myself. Since I am a very
lazy person, I try to script my work whenever possible. So why should
there be an exception for the Debian package generation, right? 😉

[…]

Right, but Debian requirements for those scripts and the environment
where they run are much tighter than yours.

I'd suggest you should start reading https://wiki.debian.org/Packaging
and it's linked pages and perhaps see some examples of current existing
packages in https://salsa.debian.org.

HTH,

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Shengjing Zhu]

On Wed, Jul 24, 2019 at 12:46 AM Shengjing Zhu  wrote:
>
> On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton  
> wrote:
> > Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
> > (easier) `dgit push-source`.
> >
>
> Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`. If
> sbuild doesn't include orig tarball in -2 source.changes, then
> `dpkg-buildpackage -S` doesn't either.
>
> Is there any option of dpkg-buildpackage to include orig tarball in -2 
> changes?
>

Find it myself, it's in dpkg-genchanges(1) and -s{i,a,d} options.

-- 
Shengjing Zhu

Re: Sorce only uploads with sbuild

[Russ Allbery]

Mathias Behrle  writes:

> I tried that building as usual with sbuild with additional option
> --source-only-changes and uploaded, but now get REJECTS with e.g.

> tryton-server_5.0.6-2.dsc: Refers to non-existing file
> 'tryton-server_5.0.6.orig.tar.gz'
> Perhaps you need to include the file in your upload?

I know people are probably getting kind of tired of the mentions of dgit,
but I personally switched over to running:

$ origtargz   # since I use pristine-tar
$ dgit --gbp build
$ dgit --gbp push-source

a while back, and it's been (mildly) life-changing.  (The --gbp is there
because I'm using gbp pq to manage diffs, mostly just due to lack of time
to do another round of investigating alternatives.)  There's a whole set
of commands and sequences that I was previously having to memorize that
just went away, and I've never had to think about different upload
commands for different suites (dgit uses the changelog to figure that out
for you), deciding whether or not to include the orig tarball, remembering
to tag the tree that I uploaded, or any of the rest of that.

Getting started with dgit felt a bit intimidating, but it basically just
worked once I got sbuild set up (and you've already crossed that hurdle),
and the payoff in reduced mental load was totally worth it.

-- 
Russ Allbery (r...@debian.org)   

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Shengjing Zhu]

On Tue, Jul 23, 2019 at 11:18 PM Sean Whitton  wrote:
> Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
> (easier) `dgit push-source`.
>

Maybe I miss something, sbuild just calls `dpkg-buildpackage -S`. If
sbuild doesn't include orig tarball in -2 source.changes, then
`dpkg-buildpackage -S` doesn't either.

Is there any option of dpkg-buildpackage to include orig tarball in -2 changes?

-- 
Shengjing Zhu

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Julian Andres Klode]

On Tue, Jul 23, 2019 at 08:18:05AM -0700, Sean Whitton wrote:
> Hello,
> 
> On Tue 23 Jul 2019 at 03:53pm +02, Mathias Behrle wrote:
> 
> > Thanks a lot, could have found myself...:(
> > TBH I didn't assume that such a bug could exist when we make source-only
> > uploads manadatory.
> 
> I find it helpful to think of sbuild as a tool for producing binaries,
> and nothing else.
> 
> If I'm doing a source-only upload then binaries are not relevant, so
> there's no need to involve a tool as complex as sbuild.
> 
> Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
> (easier) `dgit push-source`.

But we have to build inside a (clean) chroot for like stable
updates. Especially if you have native packages that generate
autotools foo, you want to generate that in stable, not in
unstable.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Sean Whitton]

Hello,

On Tue 23 Jul 2019 at 06:22PM +02, Johannes Schauer wrote:

> that is correct. Indeed the source package is the way how the sources are
> copied into the chroot so sbuild cannot operate at all without having a source
> package first. And that source package is built *outside* the chroot.
>
> That sbuild is able to build source packages itself is either a convenience
> feature or a misfeature (I'm leaning to toward the latter) because the source
> package is the *input* to sbuild, not the output.

Thanks for confirming.

I guess a possibly-helpful way to put this point would be that sbuild is
not intended to be a replacement for all of dpkg-buildpackage.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Johannes Schauer]

Hi,

Quoting Sean Whitton (2019-07-23 17:47:45)
> > I prefer to build only once, if possible, generating both binary and source
> > .changes. Both in a clean chroot. Then I can try out my .debs and on
> > success just sign and dput. Works fine for me with pbuilder.
> ICBW but I am pretty sure that sbuild builds the source package *outside* of
> the clean chroot.

that is correct. Indeed the source package is the way how the sources are
copied into the chroot so sbuild cannot operate at all without having a source
package first. And that source package is built *outside* the chroot.

That sbuild is able to build source packages itself is either a convenience
feature or a misfeature (I'm leaning to toward the latter) because the source
package is the *input* to sbuild, not the output.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Sean Whitton]

Hello,

On Tue 23 Jul 2019 at 11:23AM -04, Boyuan Yang wrote:

> To be honest, I *hate* building without clean chroot environment, no matter
> it's a source-only upload, a -2 upload or anything else. Think of this: when
> invoking sbuild, some command line options like "--source-only-changes --
> force-orig-source" have already been added but the output still does not
> contain a source tarball... why? It's certainly a bug from user's perspective.

On Tue 23 Jul 2019 at 05:30PM +02, W. Martin Borgert wrote:

> I prefer to build only once, if possible, generating both binary and
> source .changes. Both in a clean chroot. Then I can try out my .debs
> and on success just sign and dput. Works fine for me with pbuilder.

ICBW but I am pretty sure that sbuild builds the source package
*outside* of the clean chroot.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[W. Martin Borgert]

Quoting Sean Whitton :

Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
(easier) `dgit push-source`.


I prefer to build only once, if possible, generating both binary and
source .changes. Both in a clean chroot. Then I can try out my .debs
and on success just sign and dput. Works fine for me with pbuilder.

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Boyuan Yang]

在 2019-07-23二的 08:18 -0700，Sean Whitton写道：
> Hello,
> 
> On Tue 23 Jul 2019 at 03:53pm +02, Mathias Behrle wrote:
> 
> > Thanks a lot, could have found myself...:(
> > TBH I didn't assume that such a bug could exist when we make source-only
> > uploads manadatory.
> 
> I find it helpful to think of sbuild as a tool for producing binaries,
> and nothing else.
> 
> If I'm doing a source-only upload then binaries are not relevant, so
> there's no need to involve a tool as complex as sbuild.
> 
> Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
> (easier) `dgit push-source`.

To be honest, I *hate* building without clean chroot environment, no matter
it's a source-only upload, a -2 upload or anything else. Think of this: when
invoking sbuild, some command line options like "--source-only-changes --
force-orig-source" have already been added but the output still does not
contain a source tarball... why? It's certainly a bug from user's perspective.

Thanks,
Boyuan Yang


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

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Sean Whitton]

Hello,

On Tue 23 Jul 2019 at 03:53pm +02, Mathias Behrle wrote:

> Thanks a lot, could have found myself...:(
> TBH I didn't assume that such a bug could exist when we make source-only
> uploads manadatory.

I find it helpful to think of sbuild as a tool for producing binaries,
and nothing else.

If I'm doing a source-only upload then binaries are not relevant, so
there's no need to involve a tool as complex as sbuild.

Just `git clean -xdff && dpkg-buildpackage -S` and dput the result, or
(easier) `dgit push-source`.

-- 
Sean Whitton

Bug#932806: ITP: golang-github-coreos-discovery-etcd-io -- etcd discovery service

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: golang-github-coreos-discovery-etcd-io
  Version : 2+git20190513.6.78fb45d
  Upstream Author : CoreOS
* URL : https://github.com/coreos/discovery.etcd.io
* License : Apache-2.0
  Programming Lang: Go
  Description : etcd discovery service

 This package's code powers the public service at https://discovery.etcd.io.
 If you do not wish to use a public server, you can use this package to
 provide your own etcd discovery API.

Bug#932805: ITP: golang-github-rsc-devweb -- development web server

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: golang-github-rsc-devweb
  Version : 0.0~git20160115.0.29cc9e1
  Upstream Author : Russ Cox
* URL : https://github.com/rsc/devweb
* License : BSD-3-clause
  Programming Lang: Go
  Description : development web server

 This package holds a program that lets you work on a Go web server and have it
 automatically recompile on each request, like in the App Engine local
 development SDK.

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Mathias Behrle]

* Andrey Rahmatullin: " Re: Sorce only uploads with sbuild (was: Bits from the
  Release Team)" (Tue, 23 Jul 2019 15:46:08 +0500):

> On Tue, Jul 23, 2019 at 12:22:02PM +0200, Mathias Behrle wrote:
> > I tried that building as usual with sbuild with additional option
> > --source-only-changes and uploaded, but now get REJECTS with e.g.
> > 
> > tryton-server_5.0.6-2.dsc: Refers to non-existing file
> > 'tryton-server_5.0.6.orig.tar.gz'
> > Perhaps you need to include the file in your upload?
> > 
> > That's basically true, because this is a build on a version, that due to the
> > freeze wasn't uploaded yet to unstable. The version 5.0.6 got amendments,
> > thus propagating to version 5.0.6-2.  
> If it wasn't uploaded just reuse the version.

It was uploaded to a different mirror, so no option.

> > So I tried with
> > $ sbuild -A -s -d unstable --force-orig-source --source-only-changes
> > 
> > with the result, that the orig.tar.gz is included in the *amd64.changes
> > file, but it is still missing from the *source.changes file.
> > 
> > What am I missing? Did I hit a bug in sbuild?  
> Yes, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884428

Thanks a lot, could have found myself...:( 
TBH I didn't assume that such a bug could exist when we make source-only
uploads manadatory. 



-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#932801: ITP: erlang-p1-yconf -- YAML configuration processor

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: erlang-p1-yconf
  Version : 0.2019.07.18
  Upstream Author : ProcessOne
* URL : https://github.com/processone/yconf
* License : Apache-2.0
  Programming Lang: Erlang
  Description : YAML configuration processor

This library was written for ejabberd which still uses it.
It was split off into it's own project to follow Erlang/OTP guidelines
and is meant to be used in combination with erlang-p1-yaml.

Bug#932800: ITP: erlang-p1-mqtree -- index tree for MQTT topic filters

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: erlang-p1-mqtree
  Version : 1.0.3
  Upstream Author : ProcessOne
* URL : https://github.com/processone/mqtree
* License : Apache-2.0
  Programming Lang: Erlang, C
  Description : index tree for MQTT topic filters

mqtree is an Erlang NIF implementation of N-ary tree to keep MQTT topic filters
for efficient matching.
This library was written for ejabberd which still uses it.
It was split off into it's own project to follow Erlang/OTP guidelines.

Re: Debian and our frenemies of containers and userland repos

[Michael Kesper]

Hi all,

On 22.07.19 12:38, Enrico Weigelt, metux IT consult wrote:
> COOS:   just yet another special purpose distro, in that case for
>     docker hosts. neither the first, nor the last one to come.
> Yocto:  just yet another compile-yourself distro, focused on embeedded,
>     that happens to be hyped by certain corporations.
>     (for small/embedded devices, I'd really recommend ptxdist).
> Alpine: yet another distro, optimized for running in small containers

Just a shame it seems the default for everyone and their cat to use it
as a base image.

Recent article re Python container images:
https://pythonspeed.com/articles/base-image-python-docker-images/

> Containerization is a valid approach for some kind of workloads
> (eg. specific inhouse applications) that can be easily isolated from
> the rest. But it comes with the price of huge redundancies (depending
> on how huge some application stacks are). And unless everybody wants
> to go back of maintaining everything on his own, we still need distros.
> 
> If different applications need to deeply interact (eg. various plugin
> stuff, applications calling each other, etc), containerization doesn't
> help much. (eg: how can you have a pure texlive in one container and
> extra things like fonts, document classes, etc, in separate ones ? :o)
> 
> The whole point about containerization isn't about packaging and
> deployment of individual applications - instead it's about automatizing
> the rollout of fully-configured installations.

Good points!

Best
Michael



signature.asc
Description: OpenPGP digital signature

Re: Help needed with a script generating a .deb

[Shlomi Fish]

Hi Thomas!

On Tue, 23 Jul 2019 11:25:40 +0200 (CEST)
Thomas Dettbarn  wrote:

> Hello!
> 
> So, I have this awesome project, that I am trying to get into the
> package repository of Debian. I already filed an RFP, which can be
> found at the WNPP bug tracker, where it is gathering dust.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929619
> 
> So, I tried my hand at creating a package myself. Since I am a very
> lazy person, I try to script my work whenever possible. So why should
> there be an exception for the Debian package generation, right? 😉
> 
> Anyways, the script that is downloading my project, compiles it, and
> creates a .deb file can be found attached to this email, but you can
> also download it at github, at 
> 
> 
> https://github.com/dettus/ports_and_packages/blob/master/Ubuntu/games/dmagnetic/mkpackage.sh
> 

du gives an error, see
https://www.shlomifish.org/Files/files/images/Screenshot_20190723_130648.webp
.

Perhaps use "set -e -x" (or python/etc.). Did you try
https://lintian.debian.org/ yet?


> (Yes, currently I am sitting at a Ubuntu Machine (At work), but I would still
> like to see my project become part of Debian)
> 
> If you could have a look, and tell me what I might have missed, I would very
> VERY much appreciate it.
> 
> Oh, my project is located at http://www.dettus.net/dMagnetic, it is called
> dMagnetic- A Magnetic Scrolls Interpreter, and can be used to play classic
> text adventures such as "The Guild of Thieves" on modern Hardware in any
> terminal window. The graphics are being rendered in ANSI art.
> 
> 
> Thomas Dettbarn



-- 
-
Shlomi Fish   http://www.shlomifish.org/
Funny Anti-Terrorism Story - http://shlom.in/enemy

Doing linear scans over an associative array is like trying to club someone to
death with a loaded Uzi. — Larry Wall

Please reply to list if it's a mailing list post - http://shlom.in/reply .

Re: Sorce only uploads with sbuild (was: Bits from the Release Team)

[Andrey Rahmatullin]

On Tue, Jul 23, 2019 at 12:22:02PM +0200, Mathias Behrle wrote:
> I tried that building as usual with sbuild with additional option
> --source-only-changes and uploaded, but now get REJECTS with e.g.
> 
> tryton-server_5.0.6-2.dsc: Refers to non-existing file
> 'tryton-server_5.0.6.orig.tar.gz'
> Perhaps you need to include the file in your upload?
> 
> That's basically true, because this is a build on a version, that due to the
> freeze wasn't uploaded yet to unstable. The version 5.0.6 got amendments, thus
> propagating to version 5.0.6-2.
If it wasn't uploaded just reuse the version.

> So I tried with
> $ sbuild -A -s -d unstable --force-orig-source --source-only-changes
> 
> with the result, that the orig.tar.gz is included in the *amd64.changes file,
> but it is still missing from the *source.changes file.
> 
> What am I missing? Did I hit a bug in sbuild?
Yes, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884428

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Sorce only uploads with sbuild (was: Bits from the Release Team)

[Mathias Behrle]

Hi all,

in Bits from the Release Team I am told

> No binary maintainer uploads for bullseye
> =
> 
> The release of buster also means the bullseye release cycle is about to begin.
> From now on, we will no longer allow binaries uploaded by maintainers to
> migrate to testing. This means that you will need to do source-only uploads if
> you want them to reach bullseye.

I tried that building as usual with sbuild with additional option
--source-only-changes and uploaded, but now get REJECTS with e.g.

tryton-server_5.0.6-2.dsc: Refers to non-existing file
'tryton-server_5.0.6.orig.tar.gz'
Perhaps you need to include the file in your upload?

That's basically true, because this is a build on a version, that due to the
freeze wasn't uploaded yet to unstable. The version 5.0.6 got amendments, thus
propagating to version 5.0.6-2.

So I tried with
$ sbuild -A -s -d unstable --force-orig-source --source-only-changes

with the result, that the orig.tar.gz is included in the *amd64.changes file,
but it is still missing from the *source.changes file.

What am I missing? Did I hit a bug in sbuild?

Cheers,
Mathias


[1] https://wiki.debian.org/SourceOnlyUpload

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Help needed with a script generating a .deb

[Andrey Rahmatullin]

We don't use dpkg-deb -b to create packages.

If you want to create a package that can be uploaded to Debian, start with
https://mentors.debian.net/intro-maintainers

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Help needed with a script generating a .deb

[Thomas Dettbarn]

Hello!

So, I have this awesome project, that I am trying to get into the
package repository of Debian. I already filed an RFP, which can be
found at the WNPP bug tracker, where it is gathering dust.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929619

So, I tried my hand at creating a package myself. Since I am a very
lazy person, I try to script my work whenever possible. So why should
there be an exception for the Debian package generation, right? 😉

Anyways, the script that is downloading my project, compiles it, and
creates a .deb file can be found attached to this email, but you can
also download it at github, at 


https://github.com/dettus/ports_and_packages/blob/master/Ubuntu/games/dmagnetic/mkpackage.sh

(Yes, currently I am sitting at a Ubuntu Machine (At work), but I would still
like to see my project become part of Debian)

If you could have a look, and tell me what I might have missed, I would very
VERY much appreciate it.

Oh, my project is located at http://www.dettus.net/dMagnetic, it is called
dMagnetic- A Magnetic Scrolls Interpreter, and can be used to play classic
text adventures such as "The Guild of Thieves" on modern Hardware in any
terminal window. The graphics are being rendered in ANSI art.


Thomas Dettbarn

dmagnetic_to_deb.sh
Description: application/shellscript

Re: Bits from /me: Forgetting the Simplified Representation for Debian Packaging?

[Mo Zhou]

Sorry for the noise. I hereby declare that all the idea
behind the "duprkit" has died. I wish somebody else
could provide a better idea according to the original
motivations[1] in the future.

Next I'll put my focus on the recommendation document
for Debian's machine learning / deep learning packaging

  https://salsa.debian.org/lumin/deeplearning-recommendations

It was renamed from deeplearning-policy. I removed the "policy"
word from the name because I have no intention to get it merged
into Debian Policy. The document to some extent is my personal
recommendations according to my own experience and my interpretation
about software freedom. Hope it will be useful.

[1] https://github.com/dupr/duprkit/blob/master/doc/motivation.md


On 2019-07-23 07:52, Mo Zhou wrote:
> ...

Bits from /me: Forgetting the Simplified Representation for Debian Packaging?

[Mo Zhou]

Hi everyone,

This is not a new idea. I realized that the "DUPR" project
is dying. I removed all the junk from the project and extracted
very core part (redesigned after the last duprkit discussion)
of it. Here I'll present the very core part of it to you, and
let's decide whether or not to sentence the project to die.
Please give me a boolean answer.

My every move in my Debian work is more or less related
to scientific computing, where SIMD/performance matters,
although this area has always been dominated by non-free
software. At the beginning I thought "maybe we can do
something to help users obtain SIMD-enabled binary packages".
All of my attempt so far toward this direction failed:
SIMDebian, DUPR. Sorry for a series of failures, including
the deep learning one. I'm already used to failures. So
if something destine to fail, why shouldn't it fail
early?

If you don't care about the remaining very core idea of
duprkit, then this is the end of this email.
Thanks for your attention :-)

=== remaining core idea for durpkit ===

The very core idea is a simplified representation for debian
packaging, I call it "recipe". The main functionality of helper
program is to translate the information in recipe to a debian
directory. Original design was shell-based, that's ugly and
introduced learning cost since many of your familiar keywords
have been re-mapped.

In the simplest case, the Recipe is just a YAML file with
extremely similar look compared to d/control:

  https://github.com/dupr/duprkit/blob/master/examples/tq.rcp

Every key in d/control has been retained. Some extra keys
such as Debhelper-Bulidsystem are added for hinting d/rules
generation. Apart from that, the keys matching
regex("override_.*") are special: their content will be dumped
to d/rules during d/rules generation. In the above tq.rcp
case the dh_auto_test will be noop'ed.

However that's not all of the idea. Take a look at here:

 
https://github.com/dupr/duprkit/blob/master/examples/apt-nosync.rcp#L8-L16

In the YAML file, for every binary package, it's
Uppercase-char-leading attributes will be dumped to d/control,
while lowercase-char-leading attributes will be dumped to
d/. file.

You can also browse other examples in this directory:

  https://github.com/dupr/duprkit/tree/master/examples

This debian packaging representation cannot be further
shrinked. With the help of HFT, some small text files
could be conveniently embedded into the recipe.

As a side effect, I found this "recipe" very suitable
for "packaging tricks so these tricks can be managed
by dpkg", such as:

https://github.com/dupr/duprkit/blob/master/examples/py3-as-usr-bin-python.rcp
https://github.com/dupr/duprkit/blob/master/examples/fdfind-as-usr-bin-fd.rcp
https://github.com/dupr/duprkit/blob/master/examples/apt-nosync.rcp

A simple vim highlighting script for "recipe" can be found
in the repo.

Upon this "recipe" file, we can implement more things such as:

1. debian user repository. recipe-based, doesn't release
   source, no burden to review license.

2. manually hinted debian directory generation. debian
   contributores could manually write such recipe and
   convert it directly to a debian/ directory into a
   specified desination directory. To some extent I like
   to generating debian/ directory like so. dh_make and
   debmake are bounded by their weird usage, that's why
   I memorized the debian packaging template and do
   manual debianization without any helper.

3. automatic debianization. writing helpers to generate
   the simplified representation "recipe" is much easier
   than directly generating debian/ directory itself.

...

If you have ever wrote any .PKGBUILD (Archlinux build system)
file or .ebuild (Gentoo porage) file, it will be easier to
understand the design of "Recipe", since we don't have a
single-file format for directly generating .deb packages
(through multiple well-separated steps).

Ok, I'm at no mood to say more about it.
Afterall the examples are enough to present it.
So be it.