[Inx] INX is a good idea.

Karl Goetz karl at kgoetz.id.au
Sat Jan 5 15:59:41 PST 2013


Ian Rowan <imrowan at gmail.com> wrote:

> Karl, you should be all caught up now with DJ mirroring our initial
> mails to the list.

Sorry about the delay, I've been putting off replying until i had a proper computer to hand but I seem to only have time for email when i have the tablet available. As such, i tried to stick the forwarded emails together in a document, paste them in here and then reply as if they were all one big email. its ugly, missing bits (i'm sure of it) and the best I can do atm :/


> > > 1) Install Ubuntu Server 12.10, "minimal install" w/Ubuntu/ssh server
> > > roles, kernel-3.5.0-generic
> > > 2) apt-get update+upgrade; install dselect; dselect access+update
> > > [without the dselect steps I was getting way more errors from dpkg; I
> > > *think* this is due to some bug in dpkg]
> > 
> > what step do the errors exhibit at? What is the error message?
>  
> When I first gave dpkg the INX selection list, it spat out a huge list of
> warnings of "package not in database". However, the list included packages
> that I not only knew were in the database (I could see them with apt-cache
> show, and with identical names), but even some that I knew were already

Did you install architecture specific packages? Have you worked out whatcaused this since sending the email? I'd be interested to know what was behind that situation.

> installed. After a few hours of searching I was no wiser, but most people
> seemed to agree that if you did
> 
> install dselect
> dselect access
> dselect update
> 
> that it would do some good. In my case, it reduced the number of warnings
> from 296 to 71, but I still had to individually audit the remaining packages
> and find suitable replacements, which wasn't always possible. I did get it

Did you try aptitude or just apt-get? aptitude should give you similar functionality to dselect; potentially even better results (YVMV, i still use apt-get :)).

> down to a total of 10 packages that seemingly have no available alternative:

[cut big list of packages, that 10 plus others]

Thinking about how manual this process was I've been wondering if it would be possible to automate some of the process by extracting the files / binaries called by inx programatically and using dpkg to locate the package they come from.

once you have the names dpkg -S filename (for installed files) or apt-file search filename (for not installed files) will tell you what package they come from.

> > Any particular problems you expect to face withthr scripts?
> 
> Not that I can specifically point to, but I've had problems in the past with
> scripts. Fortunate for the world that I don't try to actually program. I've
> been busy with other projects since my first posts here, but should be back
> to beating on INX in a day or three.

If you do have questions feel free to ping the list, I'm trying to climb back on top of my email so hopefully i'll be able to reduce my turn around on responses to 24 hours at most.



"D.J.J. Ring, Jr." <n1ea at arrl.net> wrote:

> Karl and All:
> ---------- Forwarded message ----------
> From: "Ian Rowan" <imrowan at gmail.com>
> Date: Dec 7, 2012 11:15 PM
> Subject: Re: INX is a good idea.
> To: "DJJ Ring Jr" <n1ea at arrl.net>
> Cc: "Peter Garrett" <inx-one at optusnet.com.au>

> > When I saw your recent exchange with DJ on the mailing list, I remembered I had
> > a copy of the last INX alpha, and set to beating my head against it. I'm still
> > exploring various alternative ways of building a fresh INX based on Ubuntu
> > or Debian (obviously a long-term goal would be to make it more distro-
> > agnostic). Unsurprisingly, many of the problems I've run into have been

There was some effort put into packaging the inx scripts (for debian) as a separate package that could be installed on anything but due to some of the hacks used to get inx running that didn't seem to reach completion.

> > framebuffer- and ALSA-related, but I also face the daunting task of not
> > being a programmer and barely capable of interpreting even the most basic
> > shell scripts. In the last 48 hours alone I've looked at Debian simple-cdd,

In fairness, you seem to be starting from a very similar point to inx-one when he began the process :) Just think, with some time and input from others you could be the next inx lead dev!

> > remastersys and who knows what else. (I was actually able to get buildinx
> > to generate an INX ISO using us.archive.ubuntu.com, but that ISO completely
> > failed to boot. Then again, I did bypass the debootstrap version check :)

Did you record the error?

> > Right now I have Ubuntu Server 12.10 installed in a minimal virtual machine;
> > I was able to edit the INX selections down enough that dpkg generated no
> > warnings, but I can't figure out how to install from that package list and
> > not screw up my existing system. Sigh, that's what VM snapshots are for. Or

installing the list of packages isn't too hard, in its simplest form its 
for i in `cat list-of-packages.txt`; do apt-get -y install $i; done
or some variation thereof (alternatively you can built a big list and use apt-get one; think of it as an optomisation :))

> > I suspect, what chroot is for? Ah, yearning once more for the simplicity of
> > Slackware... Really, at this point I'd settle for just the cli/curses aspect
> > and save the framebuffer for a separate project if possible -- for me, the

probably a sensible way to go; as i recall the framebuffer stuff required setting some 'unusual' permissions on various devices.

> > package selection is half of INX, the other half is that small but crucial
> > amount of shell script and menu glue holding it all together. (And some
> > sensible default dotfiles, am I right? I haven't delved that deeply yet.)

something like that.

> > Anyway, DJ, if you could describe how you put together your Wheezy ISO with
> > working framebuffer, that would be very helpful for me; I'm doing all my
> > builds in Xen VM's, but will soon again have access to bare metal again if
> > that helps.
> >
> > I've also been in various IRC channels during this process including #inx,
> > but no activity there besides my own chatter.

I've not been on IRC much of late so I'm afraid we are unlikely to connect. OTOH if you are around during AU working hours I could probably join and put in a few words now and then.

> > PS: While I'm no kneejerk anti-Lennart Poettering type, and systemd has
> > given me no problems yet on my personal Arch box, the general direction
> > being taken by most Linux distributions is enough to give me concern and
> > increase my search for viable alternatives. The text-only ecosystem is
> > showing signs of neglect, sadly, once one wanders outside of the basics
> > (as with any desktop, I define 'texttop' basics as browsing and email).
> > NetBSD currently has ncurses bugs, etc...but this is already long and
> > rambling enough. Thanks again for your time and fine work.

The other unfortunate side effect of the neglect of the text world is the increased difficulty for blind users :(

> I remember framebuffer needing to be unblacklisted, but this may or may not
> be related: I'm running into various seeming subtle conflicts when I try to
> install these older packages on a new system like Debian Wheezy or Ubuntu
> Server Quantal. I went so far as to start installing packages manually one-

Many of the packages are bitrotting which doesn't help. if you can isolate real problems with the packages bug reports to debian/ubuntu would probably be worth doing (with appropriate usertags, i can help with that if required)

> or a-few-at-a-time from the selections list, but eventually ran into a wall
> of circular dependency hell that only grew more tangled the deeper I dug
> (what the hell do you mean, libc6:i386 and libc6-i386 aren't the same?!?).

For the record, the first is the libc6 package in the i386 section of the distribution. libc6-i386 is a package in the amd64 part of the distribution that provides a 32bit (i386) libc6 for compatibility with i386 applications running on amd64.

[1] is about multiarch as a general thing and [2] explains how to enable multiple architectures on the same system.

[1] http://wiki.debian.org/Multiarch 
[2] http://wiki.debian.org/Multiarch/HOWTO#Usage

thanks,
kk 
(Kamping_Kaiser; vk7foss)



More information about the Inx mailing list