Bug#923027: ITP: python-fire -- library for automatically generating command line interfaces (CLIs) from absolutely any Python object.

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: python-fire
  Version : 0.1.3
  Upstream Author : google
* URL : https://github.com/google/python-fire
* License : apache-2
  Programming Lang: Python
  Description : library for automatically generating command line 
interfaces (CLIs) from absolutely any Python object.

Re: Use of FATE (FFmpeg Automated Testing Envionment) data?

[Simon McVittie]

On Wed, 20 Feb 2019 at 06:19:56 +0100, Adam Borowski wrote:
> On Tue, Feb 19, 2019 at 11:52:49PM +0100, W. Martin Borgert wrote:
> > It's also a practical matter: Can I run autopkgtests, when my
> > computer is disconnected from the internet?

According to the autopkgtest specification: maybe, but not necessarily.
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst
(the title of the last section is "Network Access")

> At the very least, I'd require a "restriction" to be set -- autopkgtest
> has a system for facets like this, it'd be a good fit here.

It's been proposed in the past, but the autopkgtest maintainers
considered and rejected it. 


Maybe "Features: works-offline" (with the opposite meaning) would be
another way to represent this?

game-data-packager (in contrib) is an example of a package that tries to
test itself by downloading non-Free data from the internet, although it
looks like it currently skips the relevant test on ci.debian.net because
the testbed doesn't have the freedesktop.org DOWNLOADS directory
(usually ~/Downloads) configured.

smcv

Bug#923052: ITP: podcast -- command-line podcast player

[Robin Krahl]

Package: wnpp
Severity: wishlist
Owner: Robin Krahl 

* Package name: podcast
  Version : 0.7.5
  Upstream Author : Nathan Jaremko 
* URL : https://github.com/njaremko/podcast
* License : GPL-3.0
  Programming Lang: Rust
  Description : command-line podcast player

podcast is a command-line podcast player.  It can be used to subscribe
to podcasts using RSS feeds and to stream or download podcasts.

I intend to package podcast within the Rust packaging team.


signature.asc
Description: PGP signature

Re: merged-/usr-via-symlinks vs a-different-layout

[Guillem Jover]

On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote:
> Guillem Jover writes:
> > 3) Switching packages to the merged-/usr layout could have been
> >accomplished automatically via debhelper for a coverage of around
> >99% (?) of the archive. With something along the lines of:
> >
> >  ,---
> >  D=debian/tmp
> >  for d in /bin /sbin /lib; do
> >for p in $(find $D/$d ! -type d); do
> >  b="${p##$D/}"
> >  m="$D/usr$b"
> >  if [ ! -e "$m" ]; then
> >mkdir -p "$(dirname $m)"
> >mv "$p" "$m"
> >ln -s "${m##$D}" "$p"
> >  fi
> >done
> >  done
> >  `---
> >
> >With the property that it would handle gracefully all cases were the
> >maintainer has checked that no compat symlinks are required and has
> >then progressively moved the pathname installation to their final
> >destination under /usr.
> 
> That is not merged-/usr, but a different filesystem layout.
> 
> So, no, it is not possible to switch packages to merged-/usr this way.

You are still conflating the concept with the deployment. The
underlaying properties of merging /usr is that the contents for
directories that are present in both / and /usr get merged into
/usr.

See for example OpenSUSE which did this transition correctly:

  

> > 4) Due to having to support the broken merged-/usr-via-symlinks
> >deployment, when we want to move the contents of the binary
> >packages to the merged-/usr layout, we require now to include tons
> >of logic in (probably new) maintainer scripts, when we have been
> >trying to remove them altogether. :( With even more files untracked
> >by dpkg itself, bypassing the packaging system even more, when the
> >compat symlinks could have been shipped in the binary packages.
> 
> As far as I know maintainer scripts are only required for moving files
> from / to /usr when (a) a compat symlink is required, and (b) only when
> both merged-/usr and non-merged-/usr is supported.

I guess you are implying that we should start forcing and requiring
the broken deployment into all Debian systems… if that ever happens
I'm personally going to use any local technical means to avoid such
breakage to damage any of my systems…

Regards,
Guillem

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

[Guillem Jover]

Hi!

On Tue, 2019-02-19 at 05:49:24 +0100, Guillem Jover wrote:
> So, as part of damage control I'm going to:
> 
>   - include the Build-Tainted-By patches into dpkg 1.19.5.

Done.

>   - include a bug-script in dpkg for reportbug to report whether the
> system has been broken by the merged-/usr-via-symlinks hack.

Done.

>   - file a bug on reportbug to request reporting that for all packages.

Done. 

>   - file a bug on base-installer to request an option to install
> non-broken systems due to merged-/usr-via-symlinks.

Done. 

> I'm also pondering whether to implement checks for the broken
> merged-/usr-via-symlinks within «dpkg --audit», even though I don't
> really want to, as that would imply hardcoding Debian-specific
> pathnames in there. :(

I still have to think about this one. :/

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

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

Thanks,
Guillem

Re: merged-/usr-via-symlinks vs a-different-layout

[Ansgar]

Guillem Jover writes:
> On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote:
>> Guillem Jover writes:
>> > 3) Switching packages to the merged-/usr layout could have been
>> >accomplished automatically via debhelper for a coverage of around
>> >99% (?) of the archive. With something along the lines of:
>> >
>> >  ,---
>> >  D=debian/tmp
>> >  for d in /bin /sbin /lib; do
>> >for p in $(find $D/$d ! -type d); do
>> >  b="${p##$D/}"
>> >  m="$D/usr$b"
>> >  if [ ! -e "$m" ]; then
>> >mkdir -p "$(dirname $m)"
>> >mv "$p" "$m"
>> >ln -s "${m##$D}" "$p"
>> >  fi
>> >done
>> >  done
>> >  `---
>> >
>> >With the property that it would handle gracefully all cases were the
>> >maintainer has checked that no compat symlinks are required and has
>> >then progressively moved the pathname installation to their final
>> >destination under /usr.
>> 
>> That is not merged-/usr, but a different filesystem layout.
>> 
>> So, no, it is not possible to switch packages to merged-/usr this way.
>
> You are still conflating the concept with the deployment. The
> underlaying properties of merging /usr is that the contents for
> directories that are present in both / and /usr get merged into
> /usr.

No, I'm saying that you are proposing yet another different file system
layout.  Which is quite simple to see: the file system would differ.

You just claim it follows similar "ideas" in some way.

I can come up with other variations that move files to /usr too: have
/bin a symlink to /usr/root/bin (some for other directories).  That
would also be a different file system layout which shouldn't be called
"merged-/usr" either.

(That would have no filesystem aliasing between /bin and /usr/bin;
policy has special rules to allow replacing top-level directories with
symlinks; but besides that it is different for no good reason so I don't
think it would be a good idea.)

> See for example OpenSUSE which did this transition correctly:
>
>   

"The special comments #UsrMerge, #EndUsrMerge will help us to clean up
the spec files once everything has been moved and we can create a
general link from /bin to /usr/bin for example. "

So they want a /bin -> /usr/bin symlink (and the same for the other
directories) just as in the proposal you call broken...

Maybe you have misunderstood what SuSE plans to do?

Having dpkg track a symlink /bin/${something} and a file
/usr/bin/${something} will break should /bin be turned into a symlink
happen.  So there is no nice way to finish the transition.  I'm not sure
how that would work on RPM; maybe SuSE got stuck with that?  That would
be another good reason to not follow that way...

I wouldn't be surprised if that took about as long as the /usr/doc ->
/usr/share/doc transition.  (If the change process for most simple
changes like file locations takes 10+ years then I say the process is
broken...)

Ansgar