Re: source only upload with git-buildpackage

[Attila Szalay]

That option means that the system will create not only the binary
.amd.changes but another changes too which contains only the source
packages. And I would like to use this method to be sure the package
compiles, to be able to run the lintian against the package and even be
able to test it before the upload.

On Sat, Oct 5, 2019, 23:36 Alf Gaida  wrote:

>
> On 05.10.19 23:14, Andrey Rahmatullin wrote:
> > On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote:
>  that is miss something - my point is: Why do you invoke pbuilder (read
>  the same question about sbuild too) to create pure source packages?
> >>> To make sure they build correctly.
> >>>
> >> Ok, checked the calender, it is not April 1. I'm out.
> > --source-only-changes doesn't mean "only create the source package".
>
> Maybe i have a general problem in understanding the gbp workflow -
> thanks for the explanation.
>
>
>

Re: Bug#941708: ITP: nextcloud-server -- Nextcloud folder synchronization tool (server)

[Anthony DeRobertis]

You should fix the project license on GitLab, right now it's showing all rights 
reserved. That should be in the project settings somewhere... 

Also, have you seen ? That appears like it'll 
eventually allow a non-downloader package.

Re: Debian and our frenemies of containers and userland repos

[Jose-Luis Rivas]

On 10/5/19 12:25, Bernd Zeimetz wrote:
> 
> 
> On 10/5/19 3:31 AM, 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 but whalebuilder does.
> 
> https://github.com/metux/docker-buildpackage
> 
> 
> 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...
> 

deb-build-pkg build -o ../

https://github.com/resnullius/deb-build-pkg

It's a simple bash script. Maybe I should write better docs than the
help already available with `deb-build-pkg --help`.

It's not using k8s API but I don't see a reason why it would not be
compatible. Building a Deployment yaml on-the-fly and you're ready. Just
calling something different than the `run_docker()` function.

With deb-build-pkg you don't even need to be in a Debian system to build
stuff.

-- 

   __.https://wiki.debian.org/JoseLuisRivas
___'/___  rsa4096/D278F9C15E5461AA3C1E2FCD13EC43EEB9AC8C43

Re: source only upload with git-buildpackage

[Alf Gaida]

On 05.10.19 23:14, Andrey Rahmatullin wrote:
> On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote:
 that is miss something - my point is: Why do you invoke pbuilder (read
 the same question about sbuild too) to create pure source packages?
>>> To make sure they build correctly.
>>>
>> Ok, checked the calender, it is not April 1. I'm out.
> --source-only-changes doesn't mean "only create the source package".

Maybe i have a general problem in understanding the gbp workflow -
thanks for the explanation.

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Jeremy Stanley]

On 2019-10-05 22:13:49 +0100 (+0100), Samuel Henrique wrote:
[...]
> And the problems with relying on the tree view of email subthreads
> have already been exposed here as it depends on people formatting
> the subthread in a specific way, which does always happens.
[...]

Not necessarily. For me at least, mutt shows proper branching
subthreads regardless of whether folks remember to modify the
subject when they're changing topics. But as you already pointed
out, expecting people to use available tools which solve these
problems is unrealistic--they'd rather keep using the tools they're
familiar with and then complain about the medium--asking for (or
better still, implementing themselves) improvements in the tools
they use is going to be the last thing they consider.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Discussion tooling (was: Bits from the DPL (August 2019))

[Samuel Henrique]

On Wed, 2 Oct 2019 at 14:51, Antonio Terceiro  wrote:

> On Wed, Oct 02, 2019 at 01:37:58PM +0100, Samuel Henrique wrote:
> > On Wed, 2 Oct 2019 at 10:48, Mathias Behrle  wrote:
> >
> > > ...BTW no discussion tool can help in automating
> > > separate discussion threads when the topic changes.
> > >
> >
> > They can, I think reddit and hackernews are good at this.
> > That's the "tree-like" structure that I mentioned in my email.
>
> Note that email already has a "tree-like" structure, since forever. You
> just don't see it if you (ironically) use web application email clients
> like gmail that decided to not show it. Most console/desktop clients
> that I ever saw do support it.
>

Hm, but I wonder of the ones you saw how much they are used, because from
the ones I see people using, I would say less than 5% (by usage) has this.

And even then we are talking about tools that are either console or
desktop-only, there is still the smartphone user cases and, most
importantly, being able to follow the discussions without the need
to authenticate and being subscribed to the list, which would be
useful for outsiders (and an outsider is someone who will become
a contributor eventually).

And the problems with relying on the tree view of email subthreads
have already been exposed here as it depends on people formatting
the subthread in a specific way, which does always happens.

On Wed, 2 Oct 2019 at 15:29, Jeremy Stanley  wrote:

> If you find that mailing list discussions lack a tree-like
> structure, that's a failing of the mail client you've chosen, not
> the medium itself.


I don't think it helps with having new contributors to require them
to use specific mail clients that are used by a small niche of
mail users (talking about client percentage usage). Besides it
also require one to be subscribed to the list and authenticated,
so outsiders can't easily follow. I know there is a web interface
for the archives but is isn't good to follow the threads as well.

On Wed, 2 Oct 2019 at 15:36, Sean Whitton  wrote:

> > BTW no discussion tool can help in automating separate discussion
> > threads when the topic changes.
>
> Yes, and more generally, what we are trying to deal with seems to be a
> social problem, not a technical problem, so moving away from mailing
> lists is unlikely to have a large impact.


I don't understand the argument of it being a social problem, isn't our
own constitution a technical solution to a social problem?
When dealing with behavior/social problems, it's fine if you don't
solve 100% of the cases, but you can certainly help by having tools
that makes it harder for one to follow trough the wrong way of doing
things, that's the whole point of UX.

In this case, for example, this subthread started by saying that the
titles need to be formatted in a correct way so it's easier to follow
the big picture. Reddit and Hackernews doesn't have this problem
as you're always replying to a given comment, if it's not the OP,
it's a subthread. It's very hard to accidentally not open a subthread
when you want to, as the "add comment" screen shows you only the
one you're replying to.

In the end, I'm not saying the hackernews and reddit solution are
perfect, they still probably do have other problems when used
as a discussion tool.

I'm fine with not talking about changing the status quo anymore,
I thought there would be people exposing the problems and
talking about the pros/cons of the tools but it's clear that I'm
the outlier here. It seems most of the community doesn't think
we could have a better tool for discussions.

-- 
Samuel Henrique 

Re: source only upload with git-buildpackage

[Andrey Rahmatullin]

On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote:
> >> that is miss something - my point is: Why do you invoke pbuilder (read
> >> the same question about sbuild too) to create pure source packages?
> > To make sure they build correctly.
> >
> Ok, checked the calender, it is not April 1. I'm out.
--source-only-changes doesn't mean "only create the source package".

-- 
WBR, wRAR


signature.asc
Description: PGP signature

[What happened to CUT?] Re: Debian and our frenemies of containers and userland repos

[Nicholas D Steeves]

Bernd Zeimetz  writes:

> I'm wondering if there is something Debian can do to be even more
> successful in the container world. Like regular releases of a container
> base image from testing. The amount of packages that needed for that is
> limited, the number of RC bugs is probably low enough most of the time.
>

Maybe try resuscitating this project, possibly with a "for containers"
focus, focusing on a small subset of the available packages?

  https://cut.debian.net

On the topic of CUT, does anyone know what happened to it?


Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: source only upload with git-buildpackage

[Alf Gaida]

On 05.10.19 21:48, Andrey Rahmatullin wrote:
> On Sat, Oct 05, 2019 at 08:06:56PM +0200, Alf Gaida wrote:
>> that is miss something - my point is: Why do you invoke pbuilder (read
>> the same question about sbuild too) to create pure source packages?
> To make sure they build correctly.
>
Ok, checked the calender, it is not April 1. I'm out.


Cheers Alf

Re: source only upload with git-buildpackage

[Andrey Rahmatullin]

On Sat, Oct 05, 2019 at 08:06:56PM +0200, Alf Gaida wrote:
> that is miss something - my point is: Why do you invoke pbuilder (read
> the same question about sbuild too) to create pure source packages?
To make sure they build correctly.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian and our frenemies of containers and userland repos

[Johannes Schauer]

Hi,

Quoting Nicholas D Steeves (2019-10-05 18:41:55)
> Bernd Zeimetz  writes:
> > On 10/5/19 3:31 AM, 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?
> AFAIK sbuild has had this support for a while with --chroot-mode
> autopkgtest, --autopkgtest-virt-server (lxc, lxd, or qemu), and
> --autopkgtest-virt-server-opts='name of container goes here' will also
> do the trick; however, it's still marked experimental.
> 
>   https://manpages.debian.org/unstable/sbuild/sbuild.1.en.html
> 
> Yes, I also find it strange that one has to use arguments named
> "autopkgtest" to build on LXC, but that seems to be what the fine manual
> indicates how it works.

I also have no problem adding a docker backend to sbuild. There is a bug but
since I don't use docker I cannot test it. If anybody else would like to use
sbuild with docker you can help refine an existing proof-of-concept patch here:

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

Thanks!

cheers, josch


signature.asc
Description: signature

Re: source only upload with git-buildpackage

[Alf Gaida]

On 05.10.19 19:48, Attila Szalay wrote:
> Hi,
>
> I'm struggling with it for a while now and I couldn't find the
> solution. I have a package maintained with git-buildpackage. And now,
> that I "cannot" upload binary packages I tried to compile the new
> version with the option to create a source-only changes file too. But
> for some reason that changes files are not created.
>
Ok, not uploading binaries is default now, isn't it? Maybe i don't
understand your question right, but i've created my needed source
packages yesterday with:


gbp buildpackage -S


and uploaded them - ok, i use gbp only for a month now so it might be
that is miss something - my point is: Why do you invoke pbuilder (read
the same question about sbuild too) to create pure source packages?


Cheers Alf

source only upload with git-buildpackage

[Attila Szalay]

Hi,

I'm struggling with it for a while now and I couldn't find the solution. I
have a package maintained with git-buildpackage. And now, that I "cannot"
upload binary packages I tried to compile the new version with the option
to create a source-only changes file too. But for some reason that changes
files are not created.

I added the "pbuilder-options = --source-only-changes" option to the
[buildpackage] part of the debian/gbp.conf and when I run the "gbp
buildpackage --git-export="WC" --git-ignore-new" command I can see that the
pbuilder got this option:

I: Invoking pbuilder
I: forking: pbuilder execute --bindmounts
/home/sasa/src/debian/zorp/build-area *--source-only-changes* --buildplace
/var/cache/pbuilder/build/cow.24170 --mirror http://ftp.hu.debian.org/debian
--distribution sid --no-targz --internal-chrootexec 'chroot
/var/cache/pbuilder/build/cow.24170 cow-shell'
/usr/lib/pbuilder/pdebuild-internal
/home/sasa/src/debian/zorp/build-area/zorp-7.0.1~alpha2 --debbuildopts
 --debbuildopts  --uid 1000 --gid 1000 --pbuildersatisfydepends
/usr/lib/pbuilder/pbuilder-satisfydepends

Is there anything I can check why the non-binary changes file is not
created?

sasa@sasa:~/src/debian/zorp/src$ apt policy git-buildpackage pbuilder
cowbuilder
git-buildpackage:
  Installed: 0.9.15
  Candidate: 0.9.15
  Version table:
 *** 0.9.15 500
500 http://ftp.hu.debian.org/debian testing/main amd64 Packages
500 http://ftp.hu.debian.org/debian testing/main i386 Packages
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
500 http://ftp.de.debian.org/debian testing/main i386 Packages
100 /var/lib/dpkg/status
pbuilder:
  Installed: 0.230.4
  Candidate: 0.230.4
  Version table:
 *** 0.230.4 500
500 http://ftp.hu.debian.org/debian testing/main amd64 Packages
500 http://ftp.hu.debian.org/debian testing/main i386 Packages
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
500 http://ftp.de.debian.org/debian testing/main i386 Packages
100 /var/lib/dpkg/status
cowbuilder:
  Installed: 0.88
  Candidate: 0.88
  Version table:
 *** 0.88 500
500 http://ftp.hu.debian.org/debian testing/main amd64 Packages
500 http://ftp.de.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status

And the created files:
I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474.dsc is already in target, not
copying.
I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474.debian.tar.xz is already in
target, not copying.
I: file ../libzorp-7.0-dbgsym_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is
already in target, not copying.
I: file ../libzorp-7.0_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in
target, not copying.
I: file ../libzorp-dev_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in
target, not copying.
I: file ../munin-plugins-zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is
already in target, not copying.
I: file ../nagios-plugins-zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is
already in target, not copying.
I: file ../zorp-dbgsym_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in
target, not copying.
I: file ../zorp-modules-dbgsym_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is
already in target, not copying.
I: file ../zorp-modules_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in
target, not copying.
I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.buildinfo is already in
target, not copying.
I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target,
not copying.
I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.changes is already in
target, not copying.

Re: Debian and our frenemies of containers and userland repos

[Holger Levsen]

On Sat, Oct 05, 2019 at 07:03:06PM +0200, Bernd Zeimetz wrote:
> I'm wondering if there is something Debian can do to be even more
> successful in the container world. Like regular releases of a container
> base image from testing. The amount of packages that needed for that is
> limited, the number of RC bugs is probably low enough most of the time.
 
do?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: Debian and our frenemies of containers and userland repos

[Bernd Zeimetz]

Hi,

On 7/11/19 5:48 PM, Kyle Edwards wrote:
> The demand is there. APT-style repositories aren't going away any time
> soon.

definitely not, I think the amount of various apt repositories will rise
drastically.
>From the container world most people are in the need of a stable base
image for their containers. For that, developers also need or want the
latest shiniest software - which is something a distribution can't provide.

RedHat realized that and is providing their Universal Base Image now,
which can be freely shared in container images.

I'm wondering if there is something Debian can do to be even more
successful in the container world. Like regular releases of a container
base image from testing. The amount of packages that needed for that is
limited, the number of RC bugs is probably low enough most of the time.


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Debian and our frenemies of containers and userland repos

[Nicholas D Steeves]

Bernd Zeimetz  writes:

> On 10/5/19 3:31 AM, 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?
>>>

AFAIK sbuild has had this support for a while with --chroot-mode
autopkgtest, --autopkgtest-virt-server (lxc, lxd, or qemu), and
--autopkgtest-virt-server-opts='name of container goes here' will also
do the trick; however, it's still marked experimental.

  https://manpages.debian.org/unstable/sbuild/sbuild.1.en.html

Yes, I also find it strange that one has to use arguments named
"autopkgtest" to build on LXC, but that seems to be what the fine manual
indicates how it works.

>>> Something like docker-buildpackage ?
>> 
>> AFAICT, docker-buildpackage doesn't exist but whalebuilder does.
>
> https://github.com/metux/docker-buildpackage
>
>
> 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...
>

Sorry, I have no idea about the k8s API, or if plain LXC containers
count as containers for the purposes of this thread.  Sbuild arguments
are definitely supported by git-buildpackage though, so maybe the above
method will do the trick?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Re: Debian and our frenemies of containers and userland repos

[Bernd Zeimetz]

On 10/5/19 3:31 AM, 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 but whalebuilder does.

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


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...



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F