Search Results: "jackyf"

02 April 2017

Eugene V. Lyubimkin: experiment: optionalising shared libraries without dl_open via generating stub libraries

Reading the discussion on debian-devel about shared library dependencies in C/C++, I wondered if it's possible to link with a shared library without having an absolute dependency on it.

The issue comes often when one has a piece of software which could use extra functionality the shared library (let's call it biglib) provides, but the developer/maintainer doesn't want to force all users to install it. The common solution seems to be either:

- defining a plugin interface and a bridge library (better detailed at here);

- dlopen/dlsym to load each library symbol by hand (good luck doing that for high-level C++ libraries).


Both solutions involve dlopen at one stage or another to avoid linking with a biglib, since if you do that, the application loader will refuse to load the application unless biglib and all of its dependencies are present. But what if application is prepared to fallback at run time, and just needs a way to be able to start without biglib?

I went ahead to check what if there was a stub library to provide all symbols which the application uses (directly or indirectly) out of biglib. Turns out that yes, at least for simple cases it seems to work. I've published my experimental stub generator at https://github.com/jackyf/so-stub .

For practical use, we'd also need a way to tell the loader that a stub library has to be loaded if the real library is not found. While there is many ways to instruct the loader to load something instead of system libraries (LD_PRELOAD, LD_LIBRARY_PATH, runpath, rpath), I found no way to load something if a system library was not found. In other words, I'd like to say "dear linker/loader, when you're loading myapp: if you didn't find libfoo1.so.4 in any of system directories configured, try also at /usr/lib/myapp/stubs/ (which'd contain stubbed libfoo1.so.4)". Apparently, nothing like "rpath-fallback" exists right now. I'm considering creating a feature request for such a "rpath-fallback" if the "optional libraries via stubs" idea gets wider support.

06 July 2014

Eugene V. Lyubimkin: (Finland) FUUG foundation gives money for FLOSS development

You live in Finland? You work on a FLOSS project or a project helping FLOSS in a way or another? Apply for FUUG's limited sponshorship program! Rules and details (in Finnish): http://coss.fi/2014/06/27/fuugin-saatio-jakaa-apurahoja-avoimen-koodin-edistamiseksi/ .

14 October 2013

Eugene V. Lyubimkin: Cupt 2.6

Cupt 2.6 is released to Debian unstable. Some prominent changes, citing from NEWS-file:

19 April 2013

Eugene V. Lyubimkin: Cupt: reason chains, functional selectors and crowdfunding experiment via catincan.com

While release of Debian wheezy getting is closer and closer, Cupt's development version also moves forward bit by bit.

A couple of particularly interesting features -- showing full reason chains and functional selectors -- may be summarized by this screenshot.

And, as a fresh experiment, I placed a feature to widen functional selecting capabilities to Catincan, a (new?) crowdfunding platform for open source projects. Let's see how it goes.

21 February 2013

Eugene V. Lyubimkin: DPL game

Inspired by http://blog.zouish.org/posts/dpl_game/. The order is chosen by a fair dice roll.

Wouter Verhelst
Russ Allbery
Bill Allombert
Paul Wise

22 August 2012

Eugene V. Lyubimkin: Cupt package manager in Debian: from Squeeze to Wheezy

A status update for what changed since Squeeze release and what is the state of Cupt in Wheezy. No new things for those few who follow small blog posts or the changelog, but an overview for, maybe, softly or newly interested.

Cupt, the high-level package manager for Debian with a console interface and therefore APT's competitor, continued its development since the first stable series. In the second major version it's rewritten in C++(11), got many new features such as numerous improvements in the depedency resolver and the dpkg action scheduler, the support of index diffs, the tutorial, wget-based download method, position action override options, logging, colored action preview prompt, treeish detailed error messages if no solutions were found, to name most important. That said, if you want multiarch, CDROM repository support or, say, some exotic download method, -- Cupt won't suit, at least for now. Project-wide support is also still almost completely missing as many developers accept no more than two package managers.

The "bug-freeness" aim still holds, at the moment of writing there is no unfixed runtime bugs of priority normal+. Here I thank again those people who reported bugs, you all definitely made Cupt better. I am sure there are bugs still which wait their time to show up, but that's hardly avoidable.

All in all, 2.x is a big step forward from 1.x. Not a last step -- development continues.

17 June 2012

Eugene V. Lyubimkin: rtmpdump: error code 32

If you like me spent hours searching what does the rtmpdump's error (when trying to download live streams)

Caught signal: 13, cleaning up, just a second...
, following by

ERROR: WriteN, RTMP send error 32


mean, then after browsing many public sources (and finding no evidence there), measuring the connection throughtput (thanks to iftop program) and trying different internet providers I can, with a high level of confidence guess that error means

"your (average) connection speed is slower than what server expects, and your client is enough behind the stream that server has no more data for you"

10 April 2012

Eugene V. Lyubimkin: Cupt bits

Half a year since the last status update, so here we go:

16 February 2012

Eugene V. Lyubimkin: bureaucratic programming

Suppose that you need to write an interface to a function which draws triangles. It could look like this: (the language is a C++-based pseudocode)

void rawDrawTriangle(size_t a, size_t b, size_t c)   ...  
bool isValidTriangle(size_t a, size_t b, size_t c)
 
  return (a + b > c) && (a + c > b) && (b + c > a);
 
void drawTriangle(size_t a, size_t b, size_t c)
 
  if (max(a, b, c) > MAX_LINE_LENGTH)
   
    throw("one of sides is too big");
   
  if (!isValidTriangle(a, b, c))
   
    throw("invalid triangle");
   
  rawDrawTriangle(a, b, c);
 
void userFunction()
 
  ...
  drawTriangle(3, 5, 7);
  ...
 


And the following is how a bureaucratic version of the code could look like:

class Certificate
 
  time_t getCreationTime() const   ...  
  Certificate()   ...  
 ;
class TriangleIsValidCertificate: public Certificate
 
 public:
  const size_t a;
  const size_t b;
  const size_t c;
 private:
  TriangleIsValidCertificate(size_t a, size_t b, size_t c)   ...  
 friend class TriangleCertificationAuthority;
 ;
class TriangleCertificationAuthority
 
  static TriangleIsValidCertificate getTriangleIsValidCertificate(size_t a, size_t b, size_t c)
   
    msleep(random() * 2);
    if ((a + b > c) && (a + c > b) && (b + c > a))
     
      if (a == b && a == c)
       
        msleep(random() * 10); // hm, suspicious query
       
      return TriangleIsValidCertificate(a, b, c);
     
    else
     
      throw("invalid triangle");
     
   
 ;
class LineIsDrawableCertificate: public Certificate
 
 public:
  const size_t length;
 private:
  LineIsDrawableCertificate(size_t l)   ...  
 friend class LineCertificationAuthority;
 ;
class LineCertificationAuthority
 
  static LineIsDrawableCertificate getLineIsDrawableCertificate(size_t length)
   
    msleep(rand());
    if (length <= MAX_LINE_LENGTH)
     
      return LineIsDrawableCertificate(length);
     
    else
     
      throw("the line is too long");
     
   
 ;
void drawTriangle(size_t a, size_t b, size_t c, LineIsDrawableCertificate lineCerts[3], TriangleIsValidCertificate tivCert)
 
  msleep(rand() * 5);
  if (lineCerts[0].length != a   lineCerts[1].length != b   lineCerts[2].length != c)
   
    throw("your application is rejected");
   
  if (tivCert.a != a   tivCert.b != b   tivCert.c != c)
   
    throw("your application is rejected");
   
  if (time() - tivCert.getCreationTime() > '60 milliseconds')
   
    throw("your application is rejected");
   
  msleep(rand());
  rawDrawTriangle(a, b, c);
 
void userFunction()
 
  ...
  size_t a = 3, b = 5, c = 7;
  auto aCert = LineCertificationAuthority::getLineIsDrawableCertificate(a);
  auto bCert = LineCertificationAuthority::getLineIsDrawableCertificate(b);
  auto cCert = LineCertificationAuthority::getLineIsDrawableCertificate(c);
  auto tviCert = TriangleCertificationAuthority::getTriangleIsValidCertificate(a, b, c);
  drawTriangle(a, b, c, array(aCert, bCert, cCert), tviCert);
  ...
 

11 February 2012

Eugene V. Lyubimkin: multiarch (and) hacks

I experienced situations of writing substantial amounts of code (feature branches) for hours, days and even weeks only to find later that the written code can be thrown to the bin, either because of hidden design problem(s) or too much negative implications outweighting the positive implications of the change.

After reading some recent multiarch threads on debian-devel@ and seeing what hacks are seriously being proposed to implement only to keep the thing going, I now think that the low-level part of the Debian multiarch implementation proposal is no less broken than its high-level part, and the whole proposal is a one big hack which requires and will require more subhacks. Some will benefit from the added functionality, but all, both maintainers and users will suffer from drawbacks.

How two paragraphs above are related? We still have the time to revert the changes and say "sorry, it was a nice idea but the software world isn't ready".

05 September 2011

Eugene V. Lyubimkin: cupt: 2.2.0~rc1

It took longer than usual, but I believe it's worth.

I just released Cupt 2.2.0~rc1 to Debian experimental. To experimental, because there are important changes and I would appreciate "in-field" testing before final 2.2.0.

Here are the major changes since 2.1.x:



Enjoy and send the bug reports.

16 April 2011

Eugene V. Lyubimkin: cupt: 2.0.0

I released new major version of Cupt, 2.0.0 (== 2.0.0~rc2), today. The final list of major changes since 1.5.x is available here and in binary packages. A web copy of the (newly written) tutorial is here.

Thanks to all bug reporters who helped to make it better.

Packages have landed to Debian unstable and should be available on the mirrors soon.

21 March 2011

Eugene V. Lyubimkin: on high-level dependencies in Debian MultiArch spec

Let's assume that all low-level and file-layout work is done, and we need specifications how to make Debian high-level package managers multi-arch aware.

What we have now: only one package of the same name can be installed in the system, and packages can declare dependencies only against packages of the same architecture.

What, hence, needs to be specified:
a) are certain packages of the same name but different arches co-installable or not;
b) allow to specify foreigh arches in dependencies.

Then, how our high-level multi-arch spec could be written?

a) new field 'MultiArchCoinstallable: yes' for co-installable packages;
b) new dependency syntax: package_name[:[!]arch[,arch]...], for example: 'perl' (assuming 'perl:native' for forward dependencies like 'Depends' or 'Recommends', and 'perl:any' for Conflicts and Breaks), 'perl:amd64', 'perl:amd64,i386', 'perl:!i386', 'perl:native', 'perl:any'.

That's all. Looks easy and mostly intuitive, doesn't it? However, some people are going to implement this instead.

06 March 2011

Eugene V. Lyubimkin: cupt: 2.0.0~beta1

Cupt v2 has reached a beta stage.

Main news of Cupt v2 comparing to Cupt v1 are grouped here.

Notable changes since 2.0.0~alpha3:



Full changelog is available in debian/changelog, as usual.

binary packages for i386, source package and README

06 January 2011

Eugene V. Lyubimkin: cupt: 2.0.0~alpha3

Notable changes since 2.0.0~alpha2:

Full changelog is available in debian/changelog, as usual.

binary packages for i386, source package and README

14 November 2010

Eugene V. Lyubimkin: cupt: 2.0.0~alpha2

The second alpha of Cupt2 is out at the same download place.

Changes since first alpha:
The library API is still a subject to change. If you care, please install the documentation package and mail me (see mail address in README) your thoughts and suggestions.

26 September 2010

Eugene V. Lyubimkin: cupt: 2.0.0~alpha1

First alpha version of Cupt version 2 is available here: http://people.debian.org/~jackyf/cupt2/.

Notable changes since 1.y series:
- rewrite in C++(0x)
- improved speed;
- improved RAM usage;
- less dependencies.

All other technical details, including not yet implemented things, are described in http://people.debian.org/~jackyf/cupt2/README.

08 July 2010

Eugene V. Lyubimkin: bits about cupt

1.5.x branch

This is the branch of Cupt I intend to put into Squeeze, I fix rare bugs from time to time there. Today I uploaded the version with the support of the architecture wildcards in source packages, defined in recently released Debian Policy 3.9.0.

2.0 branch
In the same time, I started a rewrite of the whole thing to C++ to make Cupt not only (as possible) feature-rich and bug-free, but also fast, following the example of Git DVCS. I have a significant chance to finish this task before Squeeze+1 release.

18 April 2010

Eugene V. Lyubimkin: dealing with unwanted recommends using cupt

Some people use '--without-recommends' switch and the problem is gone. I think that's overkill.

This post will tell how (would I recommend) to deal with unwanted recommends. The following text tells about cupt package manager, and though ideas are applicable to any package managers, the techniques may differ.


Stage 1. Facing problems

Suppose we want to install the package kde-minimal:

-8<-
$ sudo cupt install kde-minimal
[sudo] password for jackyf:
Building the package cache... [done]
Initializing package resolver and worker... [done]
Scheduling requested actions... [done]
Resolving possible unmet dependencies...
The following 16 packages will be INSTALLED:

dolphin kappfinder kde-minimal kdebase-apps kdebase-bin kdebase-data kdepasswd
kfind kinfocenter konqueror konqueror-nsplugins kwrite libkonq5
libkonq5-templates libkonqsidebarplugin4 plasma-widget-folderview

The following 1 packages will be UPGRADED:

konsole

Need to get 6024KiB/6024KiB of archives. After unpacking 14.9MiB will be used.
Do you want to continue? [y/N/q]
->8-

Umm, kinfocenter? No, we don't want it to be installed.

Stage 2. Searching for a reason

Now we will use the 'reason tracking' feature of libcupt's resolver. Let's add '-s' switch (simulating) and '-D' switch (tracking reasons):

-8<-
$ cupt -s install kde-minimal -D
Building the package cache... [done]
Initializing package resolver and worker... [done]
Scheduling requested actions... [done]
Resolving possible unmet dependencies...
The following 16 packages will be INSTALLED:

dolphin
reason: kdebase-apps 4:4.3.4-1 depends on 'dolphin (>= 4:4.3.4-1)'

kappfinder
reason: kdebase-apps 4:4.3.4-1 depends on 'kappfinder (>= 4:4.3.4-1)'

kde-minimal
reason: user request

kdebase-apps
reason: kde-minimal 5:55 depends on 'kdebase-apps (>= 4:4.3.1)'

kdebase-bin
reason: kdebase-apps 4:4.3.4-1 depends on 'kdebase-bin (>= 4:4.3.4-1)'

kdebase-data
reason: kappfinder 4:4.3.4-1 depends on 'kdebase-data (= 4:4.3.4-1)'

kdepasswd
reason: kdebase-apps 4:4.3.4-1 depends on 'kdepasswd (>= 4:4.3.4-1)'

kfind
reason: kdebase-apps 4:4.3.4-1 depends on 'kfind (>= 4:4.3.4-1)'

kinfocenter
reason: kdebase-apps 4:4.3.4-1 recommends 'kinfocenter (>= 4:4.3.4-1)'

konqueror
reason: kdebase-apps 4:4.3.4-1 depends on 'konqueror (>= 4:4.3.4-1)'

konqueror-nsplugins
reason: kdebase-apps 4:4.3.4-1 recommends 'konqueror-nsplugins (>= 4:4.3.4-1)'

kwrite
reason: kdebase-apps 4:4.3.4-1 depends on 'kwrite (>= 4:4.3.4-1)'

libkonq5
reason: kdebase-apps 4:4.3.4-1 depends on 'libkonq5 (>= 4:4.3.4-1)'

libkonq5-templates
reason: libkonq5 4:4.3.4-1 depends on 'libkonq5-templates kdesktop'

libkonqsidebarplugin4
reason: konqueror 4:4.3.4-1 depends on 'libkonqsidebarplugin4 (>= 4:4.3.4)'

plasma-widget-folderview
reason: kdebase-apps 4:4.3.4-1 depends on 'plasma-widget-folderview (>= 4:4.3.4-1)'


The following 1 packages will be UPGRADED:

konsole
reason: synchronized with package 'kdebase-apps'


Need to get 6024KiB/6024KiB of archives. After unpacking 14.9MiB will be used.
Do you want to continue? [y/N/q]
->8-

Now, the output is much bigger. Every package has reason(s) to change its state appended. Let's look at the chain: kinfocenter is installed, because... kdebase-apps is to install. Ok, look further, kdebase-apps is to install because... of kde-minimal. The final chain is 'kde-minimal -> kdebase-apps -> kinfocenter'.

Stage 2.5. Analyzing reason

After determining a full chain one may try to think - is this dependency chain looks OK? Maybe, some Depends/Recommends should be turned up to a less strict dependencies? If that so, it's a good idea to fire a command 'reportbug <package>' to report an unwanted dependency.

In this example, the dependency chain looks OK (at least, to me :)).

Stage 3. Installing a package without unwanted dependency(ies)

The resolution of the problem depends on the answer to the question "Why I don't want this package to be installed?"

Case 1. Only this time/package

If the answer is, say, "Because dependency 'kdebase-apps -> kinfocenter' doesn't make sense on this system", then you do:

-8<-
$ sudo cupt install kde-minimal kinfocenter-
[sudo] password for jackyf:
Building the package cache... [done]
Initializing package resolver and worker... [done]
Scheduling requested actions... [done]
Resolving possible unmet dependencies...
The following 15 packages will be INSTALLED:

dolphin kappfinder kde-minimal kdebase-apps kdebase-bin kdebase-data kdepasswd kfind konqueror konqueror-nsplugins kwrite libkonq5 libkonq5-templates libkonqsidebarplugin4 plasma-widget-folderview

The following 1 packages will be UPGRADED:

konsole

Need to get 5463KiB/5463KiB of archives. After unpacking 13.2MiB will be used.
Do you want to continue? [y/N/q]
->8-

And that's all, kinfocenter won't be installed.

Consequences:

1. This answer implies that you are not against installing kinfocenter if some other package needs it. So, while installing other packages which recommend kinfocenter cupt will suggest you to install kinfocenter again.

2. If you will want to upgrade the package, and the new version contains the same relation, cupt will not suggest to install kinfocenter.

Case 2. Forever

If the answer is "Because I don't want to see kinfocenter in my system ever", then the good choice is APT pinning system.

Place the next three lines into your APT preferences file (usually, /etc/apt/preferences or any file in /etc/apt/preferences.d directory):

-8<-
Package: kinfocenter
Pin: version *
Pin-Priority: -10000
->8-

-10000 is a very low priority, usual priorities are (0 - 1000), so cupt will not ever suggest you to install kinfocenter because of soft (Recommends or Suggests) dependencies. Moreover, if in some actions cupt will need to choose between, say 'kde-virtual kde-virtual-alternate', where kde-virtual depends on kinfocenter and kde-virtual-alternate does not, then cupt will choose kde-virtual-alternate. The exceptions possible in (very unlikely to happen) cases, when non-installing kinfocenter will result in very bad solution for selected actions. The less priority kinfocenter has, the less chances it has to be installed when not requested explicitly (as in 'cupt install kinfocenter').

02 January 2010

Eugene V. Lyubimkin: cupt 1.5

Today, since a year of the first commit to the git repository, I released Cupt 1.5 and uploaded it to Debian unstable.

Notable changes since the last blog post about cupt 1.2:

1.3: various speed and RAM usage improvements
1.5: priorities for download protocols and download methods, download methods are now pluggable; bash completion for 'cupt' program

Have fun :)

Next.