Re: FTBFS on i386 for user mode linux

[Bastian Blank]

On Mon, Oct 21, 2019 at 11:28:33AM +0530, Ritesh Raj Sarraf wrote:
> I recently refreshed User Mode Linux to version 5.2 in Debian Unstable.
> The package built fine for amd64 but for i386, I have run into the
> following build failure.

What did you find about it yourself?

> ld -r -dp -o arch/um/drivers/vde.o arch/um/drivers/vde_kern.o 
> arch/um/drivers/vde_user.o  -m elf_x86_64   -r 
> /usr/lib/gcc/i686-linux-gnu/9/../../../../lib/libvdeplug.a
> ld: relocatable linking with relocations from format elf32-i386 
> (/usr/lib/gcc/i686-linux-gnu/9/../../../../lib/libvdeplug.a(libvdeplug.o)) to 
> format elf64-x86-64 (arch/um/drivers/vde.o) is not supported

grep magic shows:

| arch/um/drivers/Makefile-$(obj)/vde.o: $(obj)/vde_kern.o $(obj)/vde_user.o
| arch/um/drivers/Makefile: $(LD) -r -dp -o $@ $^ $(ld_flags)
| scripts/Makefile.lib:ld_flags   = $(KBUILD_LDFLAGS) $(ldflags-y) 
$(LDFLAGS_$(@F))

and:

| arch/x86/Makefile.um:KBUILD_LDFLAGS += -m elf_x86_64

Thie last line is guarded by "ifeq ($(CONFIG_X86_32),y) else".

The log shows:

| 64-bit kernel (64BIT) [Y/n/?] (NEW)

So, the configure step enables 64bit mode and the build tries to use it.
Is the input config complete?

Also:
- What version of linux is actually used?  There was never a 5.2, only
  5.2.x.
- 5.2 is not longer in unstable.

Bastian

-- 
Men of peace usually are [brave].
-- Spock, "The Savage Curtain", stardate 5906.5

Re: FTBFS on i386 for user mode linux

[Ritesh Raj Sarraf]

Hello Bastian,

On Mon, 2019-10-21 at 08:50 +0200, Bastian Blank wrote:
> > arch/x86/Makefile.um:KBUILD_LDFLAGS += -m elf_x86_64
> 
> Thie last line is guarded by "ifeq ($(CONFIG_X86_32),y) else".
> 
> The log shows:
> 
> > 64-bit kernel (64BIT) [Y/n/?] (NEW)
> 
> So, the configure step enables 64bit mode and the build tries to use
> it.
> Is the input config complete?
> 

That was indeed the problem. I did not pay close attention to the full
build log. The kernel config file was incomplete. After fixing the
configuration file, the package builds fine here, locally.

> Also:
> - What version of linux is actually used?  There was never a 5.2,
> only
>   5.2.x.
> - 5.2 is not longer in unstable.

It is the 5.2.x series. Like, when, a new version of the 5.2 kernel is
uploaded, say 5.2.22, just a re-build of user-mode-linux on the build
archives suffice most of the times.

Only when a new major release happens, we need to update the package
configurations.

-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response


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

Bug#942796: ITP: ruby-snowplow-tracker -- Ruby Analytics for Snowplow

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: ruby-snowplow-tracker
  Version : 0.6.1
  Upstream Author : Snowplow Analytics Ltd.
* URL : https://salsa.debian.org/ruby-team/ruby-snowplow-tracker
* License : Apache-2.0
  Description : Ruby Analytics for Snowplow
 With this tracker you can collect event data from your Ruby
applications, Ruby on Rails web applications and Ruby gems.



signature.asc
Description: OpenPGP digital signature

Re: Debian and our frenemies of containers and userland repos

[Enrico Weigelt, metux IT consult]

On 05.10.19 03:31, Paul Wise wrote:
> On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote:
>> On 24.07.19 08:17, Marc Haber wrote:
>>
>>> Do we have a build technology that uses containers instead of chroots
>>> yet?
>>
>> Something like docker-buildpackage ?
> 
> AFAICT, docker-buildpackage doesn't exist 

I'm pretty sure it does exist, since I wrote it :p

https://github.com/metux/docker-buildpackage


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Debian and our frenemies of containers and userland repos

[Enrico Weigelt, metux IT consult]

On 05.10.19 18:25, Bernd Zeimetz wrote:

Hi,

> Having something that works with git-buildpackage would be really nice,

:)

> though. Even better if it would allow to use the k8s API to build things...

Patches are always welcomed :)

There're some problems to be solved for remote hosts (IMHO, k8s only on
local node doesn't make so much sense ;-)):

dck-buildpackage currently mounts some host directories (eg. local apt
repo and reflink'ed copy of the source tree) into the container. While
one could put docker nodes into a shared filesystem, that probably
wouldn't be so nice w/ k8s ...


--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Debian and our frenemies of containers and userland repos

[Enrico Weigelt, metux IT consult]

On 07.10.19 13:17, Shengjing Zhu wrote:

> Why not have a repository for it, like dockerhub. So this becomes
> "pull latest build env", which saves lots of time("re-bootstrap" is
> still slow nowadays).

No idea how sbuild works these days (turned away from it aeons ago, as
I've found it too complicated to set up), but dck-buildpackage can do
both. It can try to pull an existing image for the given target, but
will bootstrap it when there isn't one.

IMHO, the best idea is treating images as nothing as a cache, and
having the build machinery bootstrap automatically when needed.

One thing on my 2do list for dck-buildpackage is keeping cache images
for dependency sets (eg. if the same package is rebuilt many times,
during development) - installing dependencies can eat up a lot of time.
(for now, this can be achieved manually, by configuring a target with
dependencies already installed - but I don't like manual things :o)

BTW: one important point w/ dck-buildpackage for me was being able
to specifiy what's in the image. I really prefer to have it really
minimal.



--mtx


-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Debian and our frenemies of containers and userland repos

[Enrico Weigelt, metux IT consult]

On 05.10.19 19:03, Bernd Zeimetz wrote:
 > For that, developers also need or want the
> latest shiniest software - which is something a distribution can't provide.

It can, but that needs different workflows and higher grade of
automation. (and of course wouldn't be so well tested)

Actually, I for python world I already did something: fully automatic
import and debianziation for pypi-packages. Yet experimental and part
of another tool (which I'm using for building customer specific
backport- and extra repos):

https://github.com/metux/deb-pkg/tree/wip/pypi

> I'm wondering if there is something Debian can do to be even more
> successful in the container world. 

You could use dck-buildpackage --create-baseimage to do that.
Feel free to create some target configs, and I'll be happy to add them.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Bug#942808: ITP: dropbear-rescue -- A set of initramfs scripts to add and run dropbear when the system boots in rescue mode

[Anton Avramov]

Package: wnpp
Severity: wishlist
Owner: Anton Avramov 

* Package name: dropbear-rescue
  Version : 0.1
  Upstream Author : Anton Avramov 
* URL : https://github.com/lukavia/dropbear-rescue
* License : GPL2
  Programming Lang: sh
  Description : A set of initramfs scripts to add and run dropbear when the 
system boots in rescue mode

For a long time now I've maintained servers remotely. One problem that
I've faced is what when there is problem booting I lose ability to login
remotely and help the person on premises. Further more that person can
be not technically capable or comfortable with writing console 
commands. There are instances where there is not even a keyboard or
monitor attached. 

Following dropbear-initramfs package I've decided to make a package that
will install dropbear and would have the appropriate initramfs scripts 
to start it in case the system enters rescue mode. The hooks will try 
to preserve the hostkeys so security is preserved. In addition they will
not allow password authentication. I've tried to keep the package
compatible with dropbear-initramfs package. 

Since this is my first package any suggestions or contributions are
welcome. 

I'm also looking for a sponsor for this package so others can benefit
from it if it gets included in official Debian repositories.

Bug#942810: ITP: golang-github-farsightsec-golang-framestream -- Frame Streams implementation in Go

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-farsightsec-golang-framestream
  Version : 0.2.0
  Upstream Author : Farsight Security, Inc.
* URL : https://github.com/farsightsec/golang-framestream
* License : Apache-2.0
  Programming Lang: Go
  Description : Frame Streams implementation in Go

Frame Streams is a lightweight, binary-clean protocol that allows for
the transport of arbitrarily encoded data payload sequences with minimal
framing overhead.

Bug#942811: ITP: golang-dnstap -- flexible, structured event replication format for DNS servers

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-dnstap
  Version : 0.0~git20190601.0b64a38-1
  Upstream Author : Farsight Security, Inc.
* URL : https://github.com/dnstap/golang-dnstap
* License : Apache-2.0
  Programming Lang: Go
  Description : flexible, structured event replication format for DNS 
servers

 dnstap implements an encoding format for DNS server events. It uses a
 lightweight framing on top of event payloads encoded using Protocol Buffers and
 is transport neutral.
 dnstap can represent internal state inside a DNS server that is difficult to
 obtain using techniques based on traditional packet capture or unstructured
 textual format logging.

Bug#942812: ITP: golang-github-farsightsec-go-nmsg -- Golang implementation of the nmsg network message encapsulation library

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: golang-github-farsightsec-go-nmsg
  Version : 0.0~git20190917.04d2174-1
  Upstream Author : Farsight Security, Inc.
* URL : https://github.com/farsightsec/go-nmsg
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang implementation of the nmsg network message 
encapsulation library

go-nmsg is a pure go implementation of the NMSG container and payload format 
used by the
C nmsg toolkit and library.
It can pack and unpack the protobuf structure of an NMSG payload, and the 
protobuf
structure of the data contained in the payload. It does not implement the full
functionality of the C libnmsg message modules, such as:

  - Advanced field types (e.g., a protobuf []byte as an IP address)
  - Generated fields
  - Formatting of fields for presentation and JSON output 

Re: Debian and our frenemies of containers and userland repos

[Paul Wise]

On Mon, 2019-10-21 at 18:58 +0200, Enrico Weigelt wrote:

> I'm pretty sure it does exist, since I wrote it :p
> 
> https://github.com/metux/docker-buildpackage

I couldn't find it in Debian so I incorrectly assumed, sorry.

In case you want to get it into Debian:

https://mentors.debian.net/intro-maintainers

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Merge request friendly handling of debian/changelog

[Bastian Blank]

Moin

In Debian most people prefer to have changelog entries with all changes,
so changes always contain a modification to debian/changelog.

If we also start to use merge requests on Salsa, all those changes will
contain modifications to debian/changelog, which will usualy conflict
with each other.  Or worse, are applied to an old changelog entry.  This
for example happens on the linux packaging project.

I don't think we already have a way to get around this?  Do we need
some?

There is "gbp dch", which ignores merge commits (so no really good for
merge requests), but I don't consider it to have enough control over the
content of the changelog.

The way that for example GitLab chooses in many locations is to create
split files and merge them together in the final release process.  They
now not only use that for the core software changelog[1], but also for
stuff like release posts.

So one rough idea could be:
- "dch $message" writes a dummy entry to debian/changelog if it does not
  exist and the entry to debian/changelog-unreleased/$hash.
- "dch --release" collects the snippets and creates one large entry.

Regards,
Bastian

[1]: https://docs.gitlab.com/ee/development/changelog.html
-- 
One does not thank logic.
-- Sarek, "Journey to Babel", stardate 3842.4

[RFC] Proposal for new source format

[Bastian Blank]

Hi

Debian in form of dpkg have a rather strict view on how our source
packages should look like.

- Files need to be compressed and are recorded as such, which is a hard
  problem and give rise to tools like pristine-tar and such.
- Different formats require different version formats.  The native
  sub-formats only allow native versions for example, leading to version
  mangling for packages like "linux-signed-*".
- Restrictions on what files needs to be in which tar for the quilt
  sub-format.
- The quilt sub-format can't be built without a correct orig tar.
- We have a large amount of git repositories that consists of
  source+patch, instead of read usable source, because using quilt is
  the only option we have.

During the tag2upload discussion, I think it got clear that it does not
fit anywhere.  And my standing is, that we can't implement such a
service properly without some core changes to how our sources look like.

I would like to have some comments on a large revision on the source
format.  It also needs modifications to dak to handle some parts of it.

- Source format version would be "4.0".
- Each source includes an arbitrary number of "tar" layers, which are
  applied sequentially and override files from previous steps.  I'm not
  sure if we need tombstones to be able to remove files.
- The tar files can be named the following ways:
  - $package_$version.tar
  - $package_$version.*.tar
  - $package_$upstreamversion.tar
  - $package_$upstreamversion.*.tar
- All files are recorded with their uncompressed checksum and the used
  transport compression is recorded in the dsc file.
- Either the existence of debian/patches/series or an explicit
  sub-format would do backward compatible setup with quilt.

dpkg-buildpackage would build a subset of this spec:
- .orig.tar
- .orig-*.tar
- .debian.tar

Other tools like the proposed tag2upload service can produce a different
subset.  They could ignore .orig if they don't have the info for example.

I'm missing things here, but I really would like to hear thoughts of
other people about it.  I also have no proof of concept yet.

Regards,
Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4

Re: Merge request friendly handling of debian/changelog

[Joseph Herlant]

Hi Bastian,

Full disclaimer: I probably don't contribute often enough inside
Debian to be a reference on it but thinking about it I'm wondering if
it wouldn't be easier to do it another way.

On Mon, Oct 21, 2019 at 8:06 PM Bastian Blank  wrote:
> There is "gbp dch", which ignores merge commits (so no really good for
> merge requests), but I don't consider it to have enough control over the
> content of the changelog.

I honestly generally only use gbp dch (and I reformat sometimes its
output to make it prettier).
2 reasons for that:
* it avoids conflicts when you have several MR
* it also forces me to have more relevant commit messages. Most of the
time the changelog entry I've seen in the MR is the same as the commit
message anyway so gbp dch would generate the same output, you're just
doing extra work which is already automated inside gbp dch

On another point, it would be really nice if we could have a way to
squash merge requests to avoid having the merge commit every time
cluttering the git history. I know that github has it, which lets you
rework the final commit message if you feel like it's necessary and
that allows you, as a contributor to not have to squash and force push
after each feedback for example (that also adds the MR number
automatically which is nice). I'm pretty sure there's a way to do it
in gitlab I just haven't seen it available yet in salsa.

> The way that for example GitLab chooses in many locations is to create
> split files and merge them together in the final release process.  They
> now not only use that for the core software changelog[1], but also for
> stuff like release posts.

It looks like the same idea as the reno software that openstack uses:
https://github.com/openstack/reno
But doesn't it clutter a bit your tree for things that you're going to
get in your changelog anyway in the end?

> So one rough idea could be:
> - "dch $message" writes a dummy entry to debian/changelog if it does not
>   exist and the entry to debian/changelog-unreleased/$hash.
> - "dch --release" collects the snippets and creates one large entry.

Other though, could we instead not populate the changelog inside the
MR but have a script that takes a MR as input and merges the MR using
the title of the MR as short description and description of the MR as
long description? (yes it is kind of what a merge squash does on
github)
And then use gbp dch to take care of actually updating the changelog
when the release is actually ready?

Thanks,
Joseph

Re: [RFC] Proposal for new source format

[Russ Allbery]

Bastian Blank  writes:

> I would like to have some comments on a large revision on the source
> format.  It also needs modifications to dak to handle some parts of it.

> - Source format version would be "4.0".
> - Each source includes an arbitrary number of "tar" layers, which are
>   applied sequentially and override files from previous steps.  I'm not
>   sure if we need tombstones to be able to remove files.

If we're going to go to the trouble of defining a new source format, I'd
prefer we embrace a VCS-based one rather than once again rolling our own
idiosyncratic representation of a tree of files and their history.  Even
if one is not convinced of the merits of uploading a true Git history of
the package, I think it's clear that a lot of us *do* want to do this and
see this as a very valuable step forward in providing a more complete
history of the package and of decisions made in maintaining that package.

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