Re: Which pseudo-package do ARM netboot image slices belong to?
Quoting Karsten Merker (2015-11-12 21:10:42)
> On Wed, Nov 11, 2015 at 05:07:45PM +0100, Cyril Brulebois wrote:
> > Jonas Smedegaard (2015-11-10):
> > > I've hit a bug¹ in a non-package part of Debian, identified that it is
> > > tied to variations not in package releases but web-facing parts of
> > > official Debian:
> > > http://ftp.de.debian.org/debian/dists/stretch/main/installer-armhf/$timestamp/images/netboot/SD-card-images/
> > >
> > > I filed a bugreport against the pseudo-package seeming most appropriate,
> > > but then got no (maintainer) response for a week. That delay might be
> > > perfectly fine (I often have far worse reaction time myself), but made
> > > me wonder: Did I file it wrongly, so that the bug isn't "heard"?
> > >
> > > Which pseudo-package do ARM netboot image slices belong to?
> > >
> > > or more generally:
> > >
> > > Is there some way of verifying which pseudo-package(s) is(/are)
> > > appropriate for targeting a bugreport, when web address is known?
> > >
> > > For real packages where I have located a file involved, I can verify if
> > > a proper package is targeted by use of "dpkg -L ..." or "apt-file search
> > > ..." or similar tools. Do we have similar ways to check (preferrably
> > > without needing login to specific Debian hosts) which pseudo-package
> > > some official area of Debian web services belong to? E.g. a public list
> > > of which team has write access to which parts of our web-facing
> > > services?
> > >
> > > I am aware of https://www.debian.org/Bugs/pseudo-packages but that's
> > > comparable to grep'ing package descriptions to pinpoint where a bug
> > > belongs, nowhere as accurate a verification as "dpkg -L ..." or
> > > "apt-file search ...".
> >
> > Karsten, Ian, and other arm people,
> >
> > This makes me wonder whether those sd card images should be packaged and
> > shipped somehow (through d-i-n-i or elsewhere), instead of just being
> > published through the installer-* directories.
> >
> > What's your take on this?
>
> Hello,
>
> personally I don't think that packaging the images would bring us
> an advantage that is worth the costs.
>
> Adding them to debian-installer-netboot-images would IMHO not
> really fit - d-i-n-i provides files for serving over the network
> ("real" netboot stuff, i.e. TFTP/PXE boot), while the SD-card
> images are the ARM equivalent of the i386/amd64 mini.iso, which
> we also don't package in d-i-n-i. Besides that, finding the
> proper package to report bugs against via "dpkg -L" or "apt-file
> search" also doesn't work with the binary packages generated by
> d-i-n-i, because their actual content - against which one would
> want to file a bug - is not built by d-i-n-i but by
> src:debian-installer. This could of course be changed by
> integrating d-i-n-i into the d-i build system and making the
> packages children of d-i, but from my personal point of view I
> don't see much need for that.
I agree that easy locating how to file bug is not a big benefit: That
can be addressed by adding contact info at the bottom of the web page
serving the images.
A real benefit of shipping SD card images as binary packages would be
ease of trusted bootstrapping:
Imagine Bob, a cautious but non-geekie person. He hires an expert to
carefully inspect his laptop to ensure that it is really truly running
only Debian, no other code is installed. He then wants to install
Debian on another host. He would then need to hire an expert yet again,
because he cannot - easily and secured by APT - get install media for
another machine, but needs to use different more technical trust paths
of manually downloading and verifying stuff from the big bad internet.
If d-i images was available as binary packages, then FreedomBox could
offer an install service for custom-configured laptop setups,
dynamically injecting preseeding file into a trusted installer image.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#806512: ITP: robofab -- library with objects deal with data associated with fonts and type design
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: robofab Version : 0.0.1~20151122 Upstream Author : Just van Rossum, Tal Leming, Erik van Blokland * URL : https://github.com/robofab-developers/robofab * License : BSD-3-clause Programming Lang: Python Description : library with objects deal with data associated with fonts and type design RoboFab is a Python library with objects that deal with data usually associated with fonts and type design. RoboFab has support for the UFO font format.
Bug#806513: ITP: defcon -- set of UFO based objects for use in font editing applications
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: defcon Version : 0.0.1~20151123 Upstream Author : Type Supply LLC * URL : http://code.typesupply.com * License : MIT Programming Lang: Python Description : set of UFO based objects for use in font editing applications defcon is a set of UFO based objects optimized for use in font editing applications. The objects are built to be lightweight, fast and flexible. . The objects are very bare-bones and they are not meant to be end-all, be-all objects. Rather, they are meant to provide :ref:`base functionality ` so that you can focus on your application's behavior, not :ref:`object observing ` or :ref:`maintaining cached data `.
Bug#806514: ITP: fontmath -- collection of objects that implement fast font, glyph, etc.
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: fontmath Version : 0.2~20151123 Upstream Author : Tal Leming * URL : https://github.com/typesupply/fontMath * License : MIT Programming Lang: Python Description : collection of objects that implement fast font, glyph, etc. A set of objects for performing math operations on font data.
Re: Re: localhost.localdomain
2015-11-28 3:25 GMT-02:00 Crystal Wood : > ;) You shutdow use Bottom-posting [0]. :-) 0 - http://idallen.com/topposting.html Albino
Bug#806515: ITP: pyclipper -- Cython wrapper for the C++ translation of the Angus Johnson's Clipper library
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: pyclipper Version : 0.9.3b0 Upstream Author : Maxime Chalton, Lukas Treyer, Gregor Rataj * URL : https://github.com/greginvm/pyclipper * License : MIT Programming Lang: C++ Description : Cython wrapper for the C++ translation of the Angus Johnson's Clipper library Pyclipper is a Cython wrapper exposing public functions and classes of the C++ translation of the Angus Johnson’s Clipper library.
Bug#806516: ITP: booleanoperations -- Boolean operations on paths
Package: wnpp Severity: wishlist Owner: Hideki Yamane * Package name: booleanoperations Version : 0.1 Upstream Author : Frederik Berlaen * URL : https://github.com/typemytype/booleanOperations * License : MIT Programming Lang: python, C++ Description : Boolean operations on paths Boolean operations on paths based on a super fast polygon clipper library.
Bug#806539: ITP: libdata-dump-oneline-perl -- Perl module that dumps data structures as single-line strings
Package: wnpp Owner: Lucas Kanashiro Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdata-dump-oneline-perl Version : 0.07 Upstream Author : perlancar * URL : https://metacpan.org/release/Data-Dump-OneLine * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module that dumps data structures as single-line strings Data::Dump::OneLine dumps data structures as single-line strings. It uses Data::Dmp. JSON should also encode to a single-line string, but some data structures (cyclical, contains globs or other special Perl data) cannot be encoded out of the box to JSON. Data::Dumper::OneLine strives to do the same for Data::Dumper. The package will be maintained under the umbrella of the Debian Perl Group. -- Lucas Kanashiro PGP-Key ID: RSA4096R/9883C97C PGP fingerprint: 8ED6 C3F8 BAC9 DB7F C130 A870 F823 A272 9883 C97C signature.asc Description: PGP signature
Re: Accepting cloud enablement package updates into Stable
On 11/27/2015 07:03 PM, Ben Hutchings wrote: > On Fri, 2015-11-27 at 17:49 +, Felipe Sateler wrote: >> On Fri, 27 Nov 2015 16:30:45 +, Ben Hutchings wrote: >> >>> But systemd doesn't support sysvinit scripts in runlevel S, so it would >>> still be necessary to add native systemd units. >> >> What do you mean by "doesn't support"? Systemd in debian has a patch that >> preserves ordering of runlevel S services to before anything in runlevels >> [2345]. >> >> Although it would be better indeed to have native units for all of those, >> and then drop that patch[1]. > > Right, I forgot there was this temporary patch. But it *is* temporary. > > Ben. After this discussion, I'm still not sure what needs to be done in the init script. Should we do: -# Required-Start:$local_fs $remote_fs +# Required-Start: # Required-Stop: +# X-Start-Before:networking -# Default-Start: 2 3 4 5 +# Default-Start: S # Default-Stop: 0 1 6 Cheers, Thomas Goirand (zigo)
Re: Accepting cloud enablement package updates into Stable
❦ 28 novembre 2015 21:26 +0100, Thomas Goirand : > After this discussion, I'm still not sure what needs to be done in the > init script. Should we do: > > -# Required-Start:$local_fs $remote_fs > +# Required-Start: > # Required-Stop: > +# X-Start-Before:networking > -# Default-Start: 2 3 4 5 > +# Default-Start: S > # Default-Stop: 0 1 6 Unsure too. I would say: Required-Start: $local_fs This would match the systemd file. -- "... all the modern inconveniences ..." -- Mark Twain signature.asc Description: PGP signature
RE: Tecnologia Nova Plataforma e Oportunidade de negócios.
Plataforma de tecnologia e Internet mais completa. Você não encontrará tantas ferramentas e plataformas integradas em um só lugar. Não deixe de acessar e conhecer. 1) O que é a plataforma. Acesse => http://www.omb100.com/br/share/59585 2) Torne-se um parceiro GBP ( Global Business Partner ) e ganhe com ela como um empreendedor digital. Acesse => http://www.omb100.com/br/share/59585?p1=op&p2=41 No site tem tudo explicado: sobre a empresa, informações e tudo mais detalhado. Caso não queira mais receber informações sobre tecnologia e oportunidades da área, responda "REMOVER"
vim plugin dependency and libruby
I've been helping someone with a vim plugin called vim-command-t[1] and we've both hit a snag. The problem is that when I used pbuilder it linked the plugin to libruby 2.2 but my vim is linked to libruby2.1 Now, the package has in its dependencies libruby2.2. libruby2.2 and libruby2.1 are both installed. As far as dpkg is concerned, all is well. Is there some way of putting some dependency onto vim to say "I want the vim linked to libruby2.2". One idea is to figure out what version they did link to it and put that in, but that's hard to maintain and doesn't work across architectures nicely. Generically the problem is: binary foo linked to libbar1, control file pulls in libbar1 plugin baz linked to libbar2, control file pulls in libbar2 But when foo tries to load plugin baz, it fails. Is it a problem with the plugin? Should it be using "ruby things" via the binary? - Craig [1] http://mentors.debian.net/package/vim-command-t -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: vim plugin dependency and libruby
On Sun, Nov 29, 2015 at 08:24:15AM +1100, Craig Small wrote: > I've been helping someone with a vim plugin called vim-command-t[1] and > we've both hit a snag. The problem is that when I used pbuilder it > linked the plugin to libruby 2.2 but my vim is linked to libruby2.1 Your vim is outdated, then. Vim was rebuilt over 2 weeks ago as part of the Ruby 2.2 transition. The only time there should be a discrepancy is in the middle of a transition. > Now, the package has in its dependencies libruby2.2. libruby2.2 and > libruby2.1 are both installed. As far as dpkg is concerned, all is well. > > Is there some way of putting some dependency onto vim to say "I want > the vim linked to libruby2.2". One idea is to figure out what version > they did link to it and put that in, but that's hard to maintain and > doesn't work across architectures nicely. > > Generically the problem is: > binary foo linked to libbar1, control file pulls in libbar1 > plugin baz linked to libbar2, control file pulls in libbar2 > > But when foo tries to load plugin baz, it fails. Is it a problem with > the plugin? Should it be using "ruby things" via the binary? No, it's just normal turbulence during a transition. I don't think there's anything in particular that needs to be done. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
Re: vim plugin dependency and libruby
Thanks James, If it is "just me" then its an easy fix. - Craig On Sun, Nov 29, 2015 at 8:39 AM James McCoy wrote: > On Sun, Nov 29, 2015 at 08:24:15AM +1100, Craig Small wrote: > > I've been helping someone with a vim plugin called vim-command-t[1] and > > we've both hit a snag. The problem is that when I used pbuilder it > > linked the plugin to libruby 2.2 but my vim is linked to libruby2.1 > > Your vim is outdated, then. Vim was rebuilt over 2 weeks ago as part of > the Ruby 2.2 transition. The only time there should be a discrepancy is > in the middle of a transition. > > > Now, the package has in its dependencies libruby2.2. libruby2.2 and > > libruby2.1 are both installed. As far as dpkg is concerned, all is well. > > > > Is there some way of putting some dependency onto vim to say "I want > > the vim linked to libruby2.2". One idea is to figure out what version > > they did link to it and put that in, but that's hard to maintain and > > doesn't work across architectures nicely. > > > > Generically the problem is: > > binary foo linked to libbar1, control file pulls in libbar1 > > plugin baz linked to libbar2, control file pulls in libbar2 > > > > But when foo tries to load plugin baz, it fails. Is it a problem with > > the plugin? Should it be using "ruby things" via the binary? > > No, it's just normal turbulence during a transition. I don't think > there's anything in particular that needs to be done. > > Cheers, > -- > James > GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy > > > -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: vim plugin dependency and libruby
On Sat, Nov 28, 2015 at 04:38:45PM -0500, James McCoy wrote: > On Sun, Nov 29, 2015 at 08:24:15AM +1100, Craig Small wrote: > > But when foo tries to load plugin baz, it fails. Is it a problem with > > the plugin? Should it be using "ruby things" via the binary? > > No, it's just normal turbulence during a transition. I don't think > there's anything in particular that needs to be done. An alternative, which could help during transitions, is to use "ruby things" (aka, gem2deb's dh_ruby) to build the plugin for all supported ruby versions. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
Re: apt-get source linux behaves weird
Control: tag -1 patch
Hi David,
On 15.08.2015 13:40, David Kalnischkies wrote:
> Control: tag -1 - patch
>
>> @@ -387,13 +388,15 @@ static pkgSrcRecords::Parser *FindSrc(const char
>> *Name,pkgRecords &Recs,
>> // See if we need to look for a specific release tag
>> if (RelTag != "" && UserRequestedVerTag == "")
>> {
>> -const string Rel = GetReleaseForSourceRecord(SrcList, Parse);
>> +string Dist;
>> +const string Rel = GetReleaseForSourceRecord(SrcList, Parse,
>> Dist);
>>
>> -if (Rel == RelTag)
>> +if (Rel == RelTag || Dist == RelTag)
>> {
>
> In the experimental git branch this changed completely as Release files
> have risen from the underground to be proper first class citizens (while
> Sources are still second class at best) where this was fixed by
> "accident" already in a seemingly "unrelated" commit (5ad0096a4) by me.
Since that has finally reached sid, I had another look at this bug.
>> Last = Parse;
>> Offset = Parse->Offset();
>> Version = Ver;
>> + break;
>> }
>> }
>>
>
> That 'fixes' this problem while reopening #731853 among others. Running
> the autopkgtest tests would have shown it. You can do this without
> building and installing apt packages via ./test/integration/run-tests,
> which will use the apt buildtree it is in. You need to install a bunch
> of additional test-dependencies through.
Thanks for pointing to the autopkgtests. However, some tests fail with:
"You have to build aptwerbserver or install a webserver"
But there is no aptwe*r*bserver...
One has to do:
$ cd test/interactive-helper
$ make aptwebserver
> Adding a testcase here (they are simple shell scripts with an insane
> amount of shell functions building a testing 'framework' to setup
> packages, repositories and webservers among others) wouldn't hurt the
> acceptance of a patch either.
How sane can a framework be if it has to generate packages that are "used
only by testcases and surf [...]", even though there are no waves? ;)
The relevant testcases are in test/integration/test-apt-get-source.
There is a test for #731853 that is supposed to "ensure that apt will
pick the higher version number" of 0.0.1 (stable) and 0.1 (stable).
However, this works by pure chance, as simply reversing the order
of the two insertsource lines makes the test fail.
So #731853 isn't really fixed, yet.
Actually, that's related to the problem I reported, as the underlying
issue for both is the same:
In the FindSrc function apt chooses a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or the version of the package is higher than the last best hit.
Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable),
in this order.
Looking for the version in stable, apt first selects 1.0, because the
release matches the target release, but then subsequently selects 2.0,
because the version is higher.
Looking for the version in unstable, apt first selects 2.0, because the
release matches the target release, but then subsequently selects 1.5,
because the release also matches the target release.
The correct way would be to choose a new 'best hit', if either
* there is a target release and it matches the release of the package,
* or there is no target release
and the version is higher than the last best hit.
Attached is a patch fixing this and another one adding above two
testcases.
Best regards,
Andreas
--- a/apt-private/private-source.cc
+++ b/apt-private/private-source.cc
@@ -288,6 +288,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
while ((Parse = SrcRecs.Find(Src.c_str(), MatchSrcOnly)) != 0)
{
const std::string Ver = Parse->Version();
+ bool CorrectRelTag = false;
// See if we need to look for a specific release tag
if (RelTag != "" && UserRequestedVerTag == "")
@@ -297,13 +298,10 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
{
if ((Rls->Archive != 0 && RelTag == Rls.Archive()) ||
(Rls->Codename != 0 && RelTag == Rls.Codename()))
- {
- Last = Parse;
- Offset = Parse->Offset();
- Version = Ver;
- }
+CorrectRelTag = true;
}
- }
+ } else
+CorrectRelTag = true;
// Ignore all versions which doesn't fit
if (VerTag.empty() == false &&
@@ -311,7 +309,7 @@ static pkgSrcRecords::Parser *FindSrc(const char *Name,
continue;
// Newer version or an exact match? Save the hit
- if (Last == 0 || Cache->VS().CmpVersion(Version,Ver) < 0) {
+ if (CorrectRelTag && (Last == 0 || Cache->VS().CmpVersion(Version,Ver) < 0)) {
Last = Parse;
Offset = Parse->Offset();
Version = Ver;
--- a/test/integration/test-apt-get-source
+++ b/test/integration/test-apt-get-source
@@ -27,6 +27
