gdm/xdm/login.app weirdnesses

1999-05-20 Thread solomon
I'm running potato and till recently was running XDM with login.app to
give the login screen a nice clean look.  Then GDM (Gnome Display
Manager) showed up in unstable so i grabbed it.  Next time i rebooted,
it gave me the gnome login screen and my mouse works, but for some odd
reason it disables my keyboard.  The kb works through bootup but once
it goes to the gdm login screen my led lights won't even come on & off.
 The only possible thing i can think of that i might have done was put
 login.app into the wrong runlevel or something...when i initially
 installed login.app it tried to configure before X and XDM were
 configured so it told me to configure later with some config script
 somewhere.  When it ran, it asked me which runlevel to put login.app
 into.  I know nothing about runlevels, and was given the options 2345
 ...i chose 2.  When i decided to install GDM i removed login.app
 fearing problems; when i removed it, it spit some things out about the
 runlevel stuff.  I don't remember what this said nor do i have any
 idea what it meant.  Anyway, i simply went in with a boot disk,
 renamed gdm within init.d to prevent it from booting, and then removed
 GDM, Login.app, and XDM altogether within dselect.  This has thusfar
 solved my problem; however, i sure would like to be able to have some
 freedom in choosing xdm, login.app, and gdm without worrying about
 this.  Is it simply a bug in GDM? I suppose i'll see...

_:Jared Johnson



exim mailer/dhis.org/debian mailing list question

1999-05-20 Thread solomon
Howdy all.  I'm running potato with exim mailer and i am using the
dhis.org dynamic dns service (there happens to be a nice dhis.org client
in unstable, though it would be easy enough to compile it or get
binaries...); it is set up so that mail sent to me while i'm offline is
held by dhis.org and then spooled to me when i come back online.  I
have a few debian lists set up to go into seperate folders and all,
which is spiffy.  My problem, however, is that when my mail is spooled
to me, the date & time are for when i received the messages from
dhis.org, not when they were sent to dhis.org.  This presents a problem
when TKRat and TKMail (i use both) try sorting them by date and
grouping subjects together; they don't necessarily show up in the order
of the thread.  So, i'm trying to figure out how to get exim, when it
receives the spool and delivers the message, to stamp the message with
the correct date.  Any idears?

_:Jared Johnson



Bug#953673: ITP: meeshkan -- Meeshkan is a mock server that generates realistic HTTP responses by analyzing recorded HTTP traffic, OpenAPI schemas and API documentation. It is used for testing (CI/CD)

2020-03-11 Thread Mike Solomon
Package: wnpp
Severity: wishlist
Owner: Mike Solomon 

* Package name: meeshkan
  Version : 0.2.16
  Upstream Author : Mike Solomon 
* URL : https://github.com/meeshkan/meeshkan
* License : MIT
  Programming Lang: Python
  Description : Meeshkan is a mock server that generates realistic HTTP 
responses by analyzing recorded HTTP traffic, OpenAPI schemas and API 
documentation. It is used for testing (CI/CD) and prototyping.

Meeshkan is a tool that mocks HTTP APIs for use in sandboxes as
well as for automated and exploratory testing. It uses a combination
of API definitions, recorded traffic and code in order to make crafting
mocks as enjoyable as possible.

When getting started with Meeshkan, the basic flow is *collect*,
*build* and *mock*.

1. To start, collect data from various representations and artifacts
of an API (recorded traffic, OpenAPI specifications, documentation).
2. Then, build a schema that unifies these various data sources.
3. Finally, use this schema to create a mock server of an API.

To record API traffic, the Meeshkan CLI provides a record mode that
captures API traffic using a proxy. First, run:

$ meeshkan record

Then, you can capture traffic by appending the desired URL to
the URL of the meeshkan server. The general syntax is
http://[meeshkan-host]/[url]. For example:

$ curl http://localhost:8000/http://time.jsontest.com

Meeshkan will call http://time.jsontest.com. All recorded server
traffic is written to a .jsonl log file in the http-types format.

To build a spec from recordings, run the following command:

$ meeshkan build -i path/to/recordings.jsonl

The spec is an intermediary representation of an API used
downstream for mocking.

Lastly, to spin up the mock server, run:

$ meeshkan mock -s path/to/generated/spec.json

There are several alternatives to Meeshkan, although none of them
are distributed on Debian AFAIK. Wiremock, Prism, and Hoverfly are
all good alternatives.  Where Meeshkan is different is that it
infers an API's behavior by analyzing various sources (server logs,
OpenAPI schemas and documentation) and generates responses
based on the inferred behavior. This is useful for fuzz-testing,
property-based testing and corner-case testing.

Myself and my colleagues use Meeshkan extensively for creating
mock APIs. Our proposal to add it to Debian comes after a GitLab
conference where many GitLab users reported that they only use
dependencies in their CI/CD pipelines that can be installed
using apt install. In general, we see that most companies use
bash scripts for CI/CD pipelines that make heavy use of apt
install, and we would like to make Meeshkan available to them.

Meeshkan is currently maintained by the Helsinki-based company
Meeshkan Oy in addition to a community of users, and Meeshkan Oy
will be maintaining Meeshkan for the foreseeable future.