Re: recommends for apparmor in newest linux-image-4.13

[maximilian attems]

On Thu, Nov 23, 2017 at 03:00:49PM +0100, Wouter Verhelst wrote:
> On Thu, Nov 23, 2017 at 02:18:46PM +0100, Christoph Hellwig wrote:
> > Hi all,
> > 
> > is there any good reason for the recommends of apparmor in the latest
> > linux packages?
> 
> This is in response to a discussion that happened on this list. The
> thread started in august last year[1], but really picked up speed last
> month[2] and this one[3].
> 
> The idea is that, if no critical issues are found, buster would release
> with AppArmor enabled by default. If critical issues are found, however,
> I expect the decision will be reversed (or at the least, postponed).
> 
> [1] https://lists.debian.org/debian-devel/2017/08/msg00090.html
> [2] https://lists.debian.org/debian-devel/2017/10/threads.html#00086
> [3] https://lists.debian.org/debian-devel/2017/11/threads.html#0
> 

This doesn't strike me as a discussion, but looks more like a predetermined 
setup.

Re: Processed: reassign 676001 to busybox

[maximilian attems]

On Fri, Jun 08, 2012 at 02:59:26PM +0400, Michael Tokarev wrote:
> [Adding debian-devel@ to the Cc list]
> 
> Short story (and it is short): the bug has been filed
> against initramfs-tools initially, it is about how
> /proc and /sys filesystem should be handled in initramfs
> when switching to new root.  Original reporter included
> a trivial patch for initramfs that does re-mounting of
> these filesystems.  Max reassigned it to busybox without
> giving any reasonings or comments whatsoever.  I explained
> that it is none of switch_root business, in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676001#24 ,
> and asked to not reassign bugs without giving a word of
> explanation.  After a few days of inactivity I reassigned
> this bug back to initramfs, per my explanation.  Now max
> reassigned it back.

no, no, you get the story wrong.

The bug on initramfs-tools side is fixed^Wworked-around.
I reassigned the *cloned* bug to busybox to have it properly
fixed there.

please get an ice cream and keep cool.
No need to make a drama out of a simple single bug.
 

happy hacking

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120608112824.gg8...@vostochny.stro.at

Re: Minutes of the Debian linux-2.6 Group Meeting

[maximilian attems]

On Thu, 11 Nov 2010, Marco d'Itri wrote:

> On Nov 11, maximilian attems  wrote:
> 
> > waldi proposes to remove old untouched stuff like ax25 and atm.
> Remove from where? The ATM stack is needed to support USB DSL modems,
> and while the code is not beautiful I think it can be considered mature.

ok thanks for the feedback.

the more striking examples that got lost in the transcript,
are drivers that we are building due to them beeing modular,
but that can't be possible used.
 
> > The cost of it has not yet been evaluated. We need a server box
> > with good cooling to run benchmarks with it.
> I can offer temporary access to developers to blade servers with 12
> cores (hopefully soon with 48) and plenty of RAM.
> Would a KVM guest work for you?
> The hosts run RHEL since it is more stable (sorry...), I could
> temporarily install Debian on one but it would take more time.

Ben did take that action item irc, guess this can be sorted out.

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101114162609.ga11...@stro.at

Minutes of the Debian linux-2.6 Group Meeting

[maximilian attems]

Debian Kernel Group Meeting 
===

Report by maximilian attems for the Debian Project Kernel List

The meetings were held on 3 sessions over the period of the
2 days during the Paris mini-Debconf, October 2010.

"These are the notes from the formal sessions, several informal
conversations happened which I have not made notes of, nor recorded
here." --Vince


=
Session 1
=

1st meeting session from 10:00-12:30 on 30th October 2010

Present:
Bastian Blank (waldi)
Ben Hutchings (bwh)
maximilian attems (maks)



Feature patches for wheezy
--

Input by dann frazier was noted:
"He's still good w/ what we agreed to in Portland."

Vserver is not trying to upstream. Openvz can't anymore do checkpointing
since 2.6.18 and is as well staying out of vanilla. The virtualisiation
feature patches are thus in deprecated status, they will be provided as
is, but won't be reinstated for Wheezy. It was noted that past 2.6.32
Linux containers made several nice progresses. It was agreed on
that the lxc userspace is the future recommended way.

Concerning Xen: The upstream merge of dom0 and the impressive shrink of
the patch set led to the conclusion that for the wheezy kernel that
a separate Xen feature branch anymore might not be necessary anymore.
We think to be able to add the missing patches to linux-2.6 itself.

RT is a new interesting technology that people seem to ask for.
We appeal for interested maintainer to join in in order to have it
for Wheezy.

On the TODO is to reformulate the deprecation notice in the release notes
by dannf and maks.



Switch to git
-

The switch is agreed, welcomed and looked forward post Squeeze release.
Once the stabilisation and backport period leaves enough time for that.

3 submodules parts were suggested by waldi:
  - config
  - infrastructure (scripts, maintainer)
  - linux-2.6 (maincode)

This would help not having to update infrastructure in separate branches
as we have to do now. The actual repository structure was left open for
further discussions.



Automated tests
---

This is a pressing task, we should know sooner if the specific
branch compiles and boots.

waldi shouts for reprepro, sbuild and wannbuild. Build server
needed between 6-12 hours and back then we didn't have debug yet.
People were using and testing our builds.

Action item by Ben to poke Vince for a Debian solution with
enough horse power and no bandwidth troubles.
Also the automated tests proposed at the kernel summit are to be watched.



Integrating kernel-wedge and d-i kernel packages


We have more information then kernel-wedge plus Debian Installer
Team lacks manpower to keep it update to current linux-2.6.

The action item is to replace kernel-wedge and implement the
modules splitting properly by specific dirs (like drivers/ata or
drivers/block similar to initramfs-tools).

waldi volunteers to take a look on it and implement successor.
bwh will talk with Debian boot people including otavio.



make deb-pkg


Most noted missing feature is the corresponding source to the
built deb. bwh started to look at it and plans to implement it.
maks queues a trivial patch to fix it for "paranoid" umasks.

It was further noted that thanks to the upstream linux-2.6
integration the script has seen fixes and thus improvements
by the general community. The handiness to have it around
in any git or tarball improves it's uptake.

Further documentation usage will be added to wiki or kernel
handbook by maks.



patch reduction for wheezy
--

Several patches got pushed or landed since 2.6.32, thus state
is in general good. Speakup landed finally in 2.6.37. We may
be able to use the new build configs. It was noted that noone
uses updateoldconfig thus reportallconfig beeing the interesting
target. bwh will resend his KBUILD_VERBOSE patch for both
versions of config.

We really hope to not have aufs, but instead the vfs union mounts.

lpar-console is an old patch from waldi that is actually a partial
revert on powerpc console. Action item from waldi to push it upstream.
Another go at sending doc-build-parallel.patch upstream, by bwh.
(bugfix/ia64/hardcode-arch-script-output.patch may become redundant ...,
sit it out). xorg people tell us to drop
i915-autoload-without-CONFIG_DRM_I915_KMS.patch
Ask aurel32 about sh4 patch, item by maks.



=
Session 2
=

2nd meeting seession from 12:00-13:00 on 31st October 2010
3rd meeting seession from 14:00-14:30 on 31st October 2010

Present:
Bastian Blank (waldi)
Ben Hutchings (bwh)
Julien Cristau (jcristau)
maximilian attems (maks)



DRM updates in squeeze
--

The shared tree with Ubuntu 2.6.33 stable tree was pointed out as
b

Re: Xen dom0 (core) merged to upstream Linux 2.6.37 and other new features

[maximilian attems]

On Tue, Nov 02, 2010 at 12:26:42AM +0800, Liang Suilong wrote:
> 
> NVIDIA and ATi proprietary drivers do not support xen kernel. If a trunk or
> generic kernel is built in xen pv_ops support, when users switch from normal
> mode to booting xen kernel, X server will not boot. Though we know a user
> who sets up a xen server is not a Linux newbies, the result makes user
> uncomfortable. It looks an uneasy problem.

you are on you own once you load those.
 
> Linus has released kernel-2.6.37-rc1. I read the changelog. Some Xen pvops
> patch has merged into upstream kernel. Waiting Debian to push 2.6.37-rc1 to
> experimental and test it for Xen.

experimental is currently on .36 and will stay on such until later
2.6.37-rcX (probably rc5 or such).

anyway the currently merged patches are bare dom0 support without any
backend, see http://wiki.xensource.com/xenwiki/XenParavirtOps 

P.S. please do not top post.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101102103317.gg15...@vostochny.stro.at

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[maximilian attems]

On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
> > ---
> > 1. Packages for boot loaders that need to be updated whenever the files
> > they load are modified (i.e. those that store a block list) must install
> > hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which
> > will be called on installation/upgrade and removal of kernel packages,
> > respectively.
> > 
> > The arguments given to all kernel hook scripts are the kernel ABI
> > version (the string that uname -r reports) and the absolute path to the
> > kernel image.
> 
> Currently, hook scripts invoked by a stock kernel maintainer script
> or a maintainer script from a kernel image package created by make-kpkg
> pass these exact same arguments.

no.

> But a maintainer script for a kernel
> image package created by "make deb-pkg" passes only the first argument.

no.

> Existing hook scripts rely on that difference to determine whether or
> not to take action.  For example, the initramfs hook script provided by
> the initramfs-tools package tests the number of arguments and exits
> without doing anything if more than one argument is supplied.  In other
> words, this hook script is designed to create the initial RAM file system
> for a kernel image created by "make deb-pkg", and only for a kernel
> image created by "make deb-pkg".  It does nothing otherwise.  Are you
> proposing to change this behavior?

please get your facts right before spamming the world.

kthxbye.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100628164510.gb9...@baikonur.stro.at

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

[maximilian attems]

On Mon, 28 Jun 2010, Ben Hutchings wrote:

> 2. Packages for boot loaders that need to be updated whenever the files
> they load are modified must also install hook scripts in
> /etc/mkinitramfs/post-update.d.  Initramfs builders must call these
> scripts using run-parts after they create, update or delete an
> initramfs.  The arguments given to these hook scripts are the kernel ABI
> version and the absolute path to the initramfs image.

Please rename to more generic /etc/initramfs path.
mkinitramfs is initramfs-tools specific.
otherwise ack.
 
> 3. Initramfs builders must complete their work before returning from the
> kernel postinst hook script.  [initramfs-tools currently uses a trigger
> to defer this because it can also be invoked twice, but this means it
> also has to know how to update specific boot loaders.]

not twice but multiple times, if you upgrade together for example
udev, lvm2, cryptsetup, mdadm and linux-2.6.
 
> 4. During a kernel package installation, upgrade or removal, various
> boot loader hooks may be invoked (in this order):
> 
> a. A postinst_hook or postrm_hook command set by the user or the
>installer in /etc/kernel-img.conf
> b. A hook script in /etc/mkinitramfs/post-update.d
> c. A hook script in /etc/kernel/postinst.d or .../postrm.d
> 
> To avoid unnecessary updates, the hooks invoked at step a and b may
> check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and
> do nothing in this case.  [Is this sensible or is it too 'clever'?]

what is the intent of that point?
sorry you lost me here.
 
> 5. Kernel and initramfs builder packages must not invoke boot loaders
> except via hooks.  If /etc/kernel-img.conf contains an explicit
> 'do_bootloader = yes', kernel package maintainer scripts should warn
> that this is now ignored.

for backward compat and upgrade purpose from lenny,
I think the must is wrong.
 
> 6. The installer must not define do_bootloader, postinst_hook or
> postrm_hook in /etc/kernel-img.conf.
> ---

thanks

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100628084532.ga23...@stro.at

Re: lxc linux image flavour

[maximilian attems]

On Sun, 24 Jan 2010, Suno Ano wrote:

>  Bastian> Please describe the _kernel_ improvements over the normal
>  Bastian> images. Most of it is already enabled in the default images
>  Bastian> and does not warrant for an extra image.
> 
> As you can see from http://sunoano.pastebin.com/m4b5380dc , line 29,
> Cgroup memory controller is not. This setting is mandatory if you want
> to control the available memory per containers and the like. IMO most
> folks would want that, if just to make sure their local sandbox does not
> go wild for some reason, thus eating up all memory.

if we want to ennable it for the default image, we need a benchmark
test of obvious stuff like fork()/exit to check that it didn't degrade.

if results are in the noise of the relevant benchmark we can shipp
it indeed in linux-2.6 without the need of a special featureset.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lxc linux image flavour

[maximilian attems]

On Sun, Jan 24, 2010 at 03:17:14PM +0100, Marco d'Itri wrote:
> On Jan 24, maximilian attems  wrote:
> 
> > the plan as decided in Portland was to go forward with openvz
> > if upstream provides us with a patch in time. as currently this
> > looks quite bad (latest available patch is for 2.6.27, there is
> > no sign of a patch for 2.6.32, nor any schedule like it happened
> > to be for Lenny).
> I expect that it will be released after the first beta of RHEL 6.

point to an official statement of an openvz dev.
currently it looks like they are waiting too long to be in the squeeze
boat also kernel version should match.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: lxc linux image flavour

[maximilian attems]

On Sun, Jan 24, 2010 at 03:17:14PM +0100, Marco d'Itri wrote:
> lack of the equivalent of "vzctl enter" is a critical issue for my
> applications.

looks feasable thanks to libvirt:
virsh --connect lxc:/// console v1
http://libvirt.org/drvlxc.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

lxc linux image flavour

[maximilian attems]

hello,

the plan as decided in Portland was to go forward with openvz
if upstream provides us with a patch in time. as currently this
looks quite bad (latest available patch is for 2.6.27, there is
no sign of a patch for 2.6.32, nor any schedule like it happened
to be for Lenny).

I thus propose to enable an lxc (linux containers) [1] flavour:
* Containers are sets of processes with private namespaces, which
  can look like separate boxes
* lxc is merged in linux-2.6 and continuously improved
  (the maintenance of it should be thus much lower then
   it was for openvz)
* lxc is fast and bench mark tested [2]
* the lxc userland is in sid and available for many archs
* libvirt support
* the 2.6.32 feature/fixes patch is tiny [3]
* RESOURCE_COUNTERS and CGROUP_MEM_RES_CTLR enabled
  (has overhead that is not acceptable, for general purpose images)

On the negative side it doesn't have yet checkpointing support
and not all net/ has netns support yet.


I'll wait until 1st of February and until contrary notice
would add an lxc flavour to 2.6.32.

kind regards
maks

[1] http://www.ibm.com/developerworks/linux/library/l-lxc-containers/
http://lwn.net/Articles/219794/
[2] http://lwn.net/Articles/179345/
[3] 
http://lxc.sourceforge.net/patches/2.6.32/2.6.32-rc6/share-af-unix-socket-sysctl.patch

https://lists.linux-foundation.org/pipermail/containers/2010-January/022529.html

https://lists.linux-foundation.org/pipermail/containers/2010-January/022600.html




signature.asc
Description: Digital signature

Re: OpenVZ - deb-packages

[maximilian attems]

On Wed, Oct 14, 2009 at 02:00:28PM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Wed, 14 Oct 2009, Dmitry E. Oboukhov wrote:
> > I need OpenVZ 2.6.27 with ppp-features available. I was on the
> > point of building the package, but I am not very good in building
> > of kernels and the current openvz is built somehow strange:
> > apt-get source linux-image-2.6.26-2-openvz-686 gets an src-package
> > with no mentions of openvz in debian/control in it.
> 
> Kernel packages are special:
> http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage
> 
> > 1. Have I understood correctly that openvz doesn't have its own Source
> > in Debian now and it is simply added/removed from linux-source as the
> > need arises? How should I act and with whom should I communicate if I
> > want to add something to the package?
> 
> The main source is the linux-2.6 source package. You should talk to its
> maintainers (people reachable on debian-ker...@lists.debian.org).
> 
> > 2. May be somebody has already built openvz 2.6.27 (with ppp-features).
> > Could You share the link on repository?
> 
> I have built a 2.6.26 openvz kernel with the ppp support (a single
> supplementary patch):
> 
> The patch on the source package:
> https://svn.ac-grenoble.fr/svn/slis/slis/sources/trunk/backports/patches/linux-2.6_2.6.26-15~slis41+1.patch
> 
> The source package:
> http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-2.6_2.6.26-15~slis41+1.dsc
> 
> The binary package:
> http://ftp.slis.fr/slis/pool/main/l/linux-2.6/linux-image-2.6.26-slis.1-openvz-686_2.6.26-15~slis41+1_i386.deb
> 
> I would like this patch to be added in a point release update given it's
> only a supplementary feature in the -openvz kernel and should not disturb
> anything else. But it's not in line with the traditional stable update
> policy so I did not bother to propose it up to now.
> 
> Dann, what's your stance on this ?

I'm taking care of openvz, please file a bug report with severity
important including the patch or link to patch, so that it can be added.

if it does not break ABI it is easiest to add to next stable release,
if it does i'll add it to the queued ABI breaking patches.
did you test that?

thanks + kind regards

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Patch Tagging Guidelines (aka DEP3)

[maximilian attems]

On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote:
> 
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/

at a quick look this again seems to have degenerated in lots
of Debianism:

* Why using "Description" for subject?
  "Author" instead of From..

* Why not reqesting the patches to be "git am" appliable.
  this way quilt understands them, they can be easily be
  bounced of to upstream thanks to existing tools.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Coordinating efforts to get a new kernel in testing?

[maximilian attems]

On Sat, Jul 11, 2009 at 01:08:05PM +0200, Luk Claes wrote:
> 
> It needs quite some work to get reverse dependencies handled and getting
> it built on all architectures. Both of which are the main responsability
> of the kernel team...

it is mostly done, beside the strange cpio missing build dep,
that funnily surfaced now on i686. fixed in latest repo and
scheduled for upload latest on this upcoming week.
 
> > Could this be prioritized by the involved teams (mostly kernel and
> > release, I'd guess) or are there already some plans for this to
> > happen?
> 
> There are no plans to force anything in like some propose in such
> situations as there is no clear plan of the kernel team to get the
> remaining issues solved soon after it would be forced in.

without force hints linux-2.6 goes nowhere.

what are the remaining issues that you are concerned about?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

usplash up to adoption

[maximilian attems]

no time to sync with ubuntu upstream, latest Debian can be found in
git://git.debian.org/collab-maint/usplash.git


-- 
maks

ps please keep on Cc, thanks!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux-libre for Debian Lenny

[maximilian attems]

On Thu, Apr 23, 2009 at 11:21:56AM +0200, Robert Millan wrote:
> 
> As you probably know, back in December last year it was decided [1] that the
> Linux package shipped with Debian Lenny would include non-free code in it
> (so-called "blobs" of binary-only firmware).
> 
> While the majority of the project supported this decision, it is still true
> that many of us users and developers feel strongly committed to freedom, and
> would rather reject the practical benefit of that code than submit ourselves
> to the restrictions that come with it.
> 
> This is to announce that Debian packages of Linux-libre [2] are now available
> for Lenny users who want to use them:
> 
[snipp links]

no point in posting that to devel announce.
this work is pointless and has no review at all by the debian kernel team.

if you want a working and dfsg free converging linux-2.6 use our sid packages.
we are actively working with upstream in getting allmost all drivers
using request_firmware() and providing the corresponding linux-firmware
in non-free. see http://wiki.debian.org/KernelFirmwareLicensing for
status. excluding drivers/staging 2.6.29 is allmost there, upcoming
2.6.30 has further request_firmware() and dfsg improvements.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re : squeeze and the future of the alpha port, redux

[maximilian attems]

On Mon, Feb 23, 2009 at 09:59:31AM +0100, Arthur Loiret wrote:
> 
> 2009/2/20, Steve Langasek :
> > Also unsurprisingly (to me, given my observations that had led to the post
> > in the first place), no one else has yet stepped up to be an alpha porter
> > for squeeze.
> 
> I am volunteer to apply as alpha porter. I have several alpha machines
> of my own, which makes it easy to debug a failure on alpha.

no only due to the demand post release,
it is good to rethink the end of life of alpha.
 
> > I've cc:ed everyone who listed themselves as an alpha porter for etch on
> > , to make sure
> > anyone willing to do the work on alpha for Squeeze has an opportunity to do
> > so.  But in the absence of some demonstration of committment in the next
> > couple of weeks, on March 7 I'll plan to ask the ftp team and the release
> > team to drop alpha from the archive for testing and unstable.
> 
> I can provide access to some hardware if anybody else is interested in
> contributing to the alpha port.

it be cool to have a kernel alpha buildserver so that alpha
get autobuild before upload.

i'd volounteer in refreshing the config settings for alpha on linux-2.6
side, they haven't seen care for quite some time.

kind regards

-- 
maks


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Is it a "user error" to use lilo?

[maximilian attems]

On Wed, Aug 27, 2008 at 05:24:36PM +0200, Bjørn Mork wrote:
> At the moment, http://svn.debian.org/wsvn/kernel/people/waldi/dkt/ seems
> to be the best source of information about this project.  Is that correct?

yep it allmost got shipped with lenny and there is enough time to clear
things for lenny+1

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: packages up for adoption

[maximilian attems]

On Wed, Aug 27, 2008 at 05:32:27PM +0200, Thomas Viehmann wrote:
> Steve Langasek wrote:
> >> arthur loiret nmu uploaded latest upstream to experimental,
> >> so those are for him.
> 
> > Where by "NMU" you mean "made an improper upload claiming to be the
> > maintainer of a package that was not up for adoption"?
> 
> If he did not talk to James first, that is pretty bad and James deserves
> an apology. On the other hand, once the package is up for adoption,
> fixing 14 bugs seems like a relatively strong application for its
> maintenance even if it's only by housekeeping and new upstream versions.

right i should have uploaded to delayed.
arthur apologised to james afaij
he is right now 3 days on vac, but will be back soonest
and ready to take care of the gawk, gawk-doc, mawk packages.

sunny greetings

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is it a "user error" to use lilo?

[maximilian attems]

On Wed, Aug 27, 2008 at 09:07:29AM -0500, William Pitcock wrote:
> 
> If you have both GRUB and LILO installed, there will be problems. That
> is infact, a bug. They should Conflict with each other to ensure that
> only one can be installed at a time, but it is a minor bug at best, as
> any smart user would not have both bootloaders installed. And infact,
> any typical user would not install a second bootloader.

things are sorted by the run_bootloader variable in /etc/kernel-img.conf

user had switched from lilo to grub without changing this preference,
thus user error.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is it a "user error" to use lilo?

[maximilian attems]

On Wed, Aug 27, 2008 at 02:02:06PM +0200, Bjørn Mork wrote:
> maximilian attems <[EMAIL PROTECTED]> writes:
> 
> > kernel-img.conf(5) has nothing to do with initramfs-tools.
> > there you'll find do_bootloader documented.
> 
> I am glad you are referring to this man page.  I found myself looking
> for it a while ago, surprised to find that it wasn't installed on the
> system in question.  A little searchin told me that was because it's
> part of kernel-package and therefore not installed on most systems
> having a /etc/kernel-img.conf file.
> 
> Maybe this essential documentation should be split out to a separate
> package depended on by initramfs-tools, linux-image-* and possibly other
> packages using /etc/kernel-img.conf?

kernel-img.conf does not pertain to any package, this is meant to be solved
postlenny by linux images using debian kernel toolkit [1]

kind regards

-- 
maks

[1] http://multibuild.org/documentation/dkt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Is it a "user error" to use lilo?

[maximilian attems]

On Wed, Aug 27, 2008 at 12:43:10PM +0200, Jonas Smedegaard wrote:
> Hi fellow developers,
> 
> Please someone help look at bug#494422.
> 
> What is wrong with my judgement[1]?

you are totaly misinformed as usual,
don't mess with bugs you have zero knownledge with.
 
 
> It seems to me that bug#494422 origins as the fix for bug#356850[2]
> 
> Generally I am worried about initramfs-tools being so invasive (see 
> bug#494422 - especially Max seemingly recommending[3] to reinstall from 
> time to time - slowly upgrading is not expected to work).

kernel-img.conf(5) has nothing to do with initramfs-tools.
there you'll find do_bootloader documented.

kthxbye

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: packages up for adoption

[maximilian attems]

hello,

On Tue, Aug 26, 2008 at 10:46:33PM +0100, James Troup wrote:
> 
> The following packages are up for adoption:
> 
>  * gawk
>  * gawk-doc (non-free)

arthur loiret nmu uploaded latest upstream to experimental,
so those are for him.

thanks

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Xen status in lenny?

[maximilian attems]

On Fri, Jul 18, 2008 at 11:44:53AM +0200, Bastian Blank wrote:
> On Fri, Jul 18, 2008 at 11:23:19AM +0200, maximilian attems wrote:
> > On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote:
> > > On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
> > > > right but still no excuse to bring in a patch set that is *known*
> > > > to not be merged upstream.
> > > So OpenVZ is also out of reach.
> > openvz is actively working on namespace merge and using the emerging
> > bits. their patchsize is decreasing.
> 
> Which does not change the fact that the patch in this form will never be
> accepted.

sure patchsets of such size are never gobed in *one* step.

here you'll find a nice metric on their merge success:
http://community.livejournal.com/openvz/22369.html


-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Xen status in lenny?

[maximilian attems]

On Fri, Jul 18, 2008 at 11:08:43AM +0200, Bastian Blank wrote:
> On Fri, Jul 18, 2008 at 01:04:45AM +0200, maximilian attems wrote:
> > right but still no excuse to bring in a patch set that is *known*
> > to not be merged upstream.
> 
> So OpenVZ is also out of reach.

openvz is actively working on namespace merge and using the emerging
bits. their patchsize is decreasing.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Xen status in lenny?

[maximilian attems]

On Fri, Jul 18, 2008 at 09:57:29AM +0200, Tollef Fog Heen wrote:
> 
> Of course it is when it is to prevent a fairly substantial regression
> from etch.  Whether etch should have shipped a dom0 or not is a
> different question and a little late to complain about now; we just have
> to do the best we can with what we have.

an lenny+half with upstream merged version makes sense indeed.
until then people can rely on etch + etch unofficial images.

the regression would have been *huge* if we had no guest image support
at all, but that got fixed and is tested.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Xen status in lenny?

[maximilian attems]

On Fri, Jul 18, 2008 at 12:45:21AM +0200, Bastian Blank wrote:
> On Thu, Jul 17, 2008 at 05:34:28PM +0300, Pasi Kärkkäinen wrote:
> > That SLES forward-port for 2.6.26 is not acceptable based on Debian kernel
> > patch policy: http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
> 
> Which is only the case for the main images. We have support for
> additional feature sets, which have less strict rules.

right but still no excuse to bring in a patch set that is *known*
to not be merged upstream.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[maximilian attems]

On Wed, Jul 16, 2008 at 09:44:00PM +0300, Pasi Kärkkäinen wrote:
> On Wed, Jul 16, 2008 at 07:26:48PM +0200, maximilian attems wrote:
> > On Wed, Jul 16, 2008 at 07:53:52PM +0300, Teodor wrote:
> > > On Wed, Jul 16, 2008 at 2:49 PM, Pasi Kärkkäinen <[EMAIL PROTECTED]> 
> > > wrote:
> > > >> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> > > >> > > I think x86-64 xen patches are going in for 2.6.27..
> > > >
> > > > Lenny will not support 64bit, no dom0.. so basicly lenny can only be 
> > > > used as
> > > > a 32bit domU .. unless people build/get some other dom0 kernel.
> > > 
> > > What about the patches for x86-64 support in domU? If these are going
> > > to be included in 2.6.27 does it mean they qualify [1] to be included
> > > in the kernel for lenny?
> > 
> > no.
> > please read a thread before posting to it, that question is already
> > answered twice.
> > 
> 
> btw out of curiosity do you know if the kernel patch policy was different 
> earlier (for etch), because xen kernel for etch (2.6.18-*-xen-686) contains 
> non-upstream xen patches (from xensource).. 

xen upstream back then ported forward their own patches *and* everybody
expected their patches to be merged. earliest merge plans were floating
for 2.6.15.

reliance on external patches is always bad, kvm is in kernel.
it doesn't try to duplicate dog and cat, but uses linux scheduler
itself and so on..

also if release team still decides to push for 2.6.25, which is
possible if 2.6.26 turns out bad, you still have much less xen
features.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[maximilian attems]

On Wed, Jul 16, 2008 at 07:53:52PM +0300, Teodor wrote:
> On Wed, Jul 16, 2008 at 2:49 PM, Pasi Kärkkäinen <[EMAIL PROTECTED]> wrote:
> >> > > See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> >> > > I think x86-64 xen patches are going in for 2.6.27..
> >
> > Lenny will not support 64bit, no dom0.. so basicly lenny can only be used as
> > a 32bit domU .. unless people build/get some other dom0 kernel.
> 
> What about the patches for x86-64 support in domU? If these are going
> to be included in 2.6.27 does it mean they qualify [1] to be included
> in the kernel for lenny?

no.
please read a thread before posting to it, that question is already
answered twice.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[maximilian attems]

On Wed, Jul 16, 2008 at 07:11:06AM -0500, William Pitcock wrote:
> 
> Without dom0, lenny will be unusable for several installations of mine
> which presently run an ugly combination of etch's dom0 and lenny's
> kernel. I would like to do that in a different way.
> 
> If we will not see dom0 in linux-2.6 on Debian, we should at least have
> a 2.6.18 tree with dom0.

no.
we will not have 2 different linux-2.6 versions in Lenny.
please think of the implications before throwing out suggestions.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[maximilian attems]

On Wed, Jul 16, 2008 at 02:23:26PM +0300, Pasi Kärkkäinen wrote:
> Like said, this thread was started to discuss about possible options of
> getting xen dom0 support into lenny, and I pasted that git link to give a
> status update of pv_ops work happening atm.
 
current best guess is lenny+half.

having seen the lessons of etch+half and with the established procedure
we should start sooner. 4 upstream version after the release as goal.
that would be 2.6.30 if naming stays the same. most probably this
would have much wider xen support including dom0.

there still exists the unofficial waldi's dom0 2.6.18 latest xen branch
based kernels.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[maximilian attems]

On Wed, Jul 16, 2008 at 12:51:21PM +0300, Pasi Kärkkäinen wrote:
> On Wed, Jul 16, 2008 at 10:50:22AM +0200, maximilian attems wrote:
> > On Wed, 16 Jul 2008, Ben Hutchings wrote:
> > 
> > > On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> > > 
> > > > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > > > important Xen kernel features ported to pv_ops framework and integrated 
> > > > into vanilla linus kernels soon.. 
> > > > 
> > > > Status/todo:
> > > > http://wiki.xensource.com/xenwiki/XenParavirtOps
> > > > 
> > > > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > > > http://fedoraproject.org/wiki/Features/XenPvopsDom0
> > > 
> > > SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> > > available any day now from
> > > <ftp://ftp.suse.com/pub/projects/kernel/kotd/SL110_BRANCH/i386/>.  Is it
> > > possible that those patches will be usable in lenny, as I believe the
> > > kernel team expects to release with Linux 2.6.26?
> > 
> > dom0 looks currently out of reach,
> > what we have is the snapshotting features of 2.6.27 for x86_32.
> > 
> 
> Hmm.. what do you mean with "out of reach" ? pv_ops dom0 is not yet
> ready/working, but those SLES 11 patches have the xensource (2.6.18 forward
> port) of dom0 and all the other xen kernel features for 2.6.26.. 

sorry but no please read
http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines

pv_ops is the upstream way we enabled them in 2.6.25 and
enhance the existing 2.6.26 base.
what are you moaning?
 
> > see relevant posts of Ian Campbell on d-kernel
> > 
> 
> You mean this?: http://lists.debian.org/debian-kernel/2008/07/msg00070.html
> 
> I think the situation has changed after that.. 
> 
> See: http://wiki.xensource.com/xenwiki/XenParavirtOps
> 
> I think x86-64 xen patches are going in for 2.6.27.. 
> 
> http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=summary
> 
> "9 hours ago  Ingo Molnar Merge branch 'xen-64bit'"

right but you seem to have zero idea about the x86 upstream git
tree and it's dependencies. the merge of that is out of question
for the upcoming stable kernel.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Xen status in lenny?

[maximilian attems]

On Wed, 16 Jul 2008, Ben Hutchings wrote:

> On Tue, Jul 15, 2008 at 05:22:55PM +0300, Pasi Kärkkäinen wrote:
> 
> > Hopefully Jeremy Fitzhardinge (from Xensource) and others can get the
> > important Xen kernel features ported to pv_ops framework and integrated 
> > into vanilla linus kernels soon.. 
> > 
> > Status/todo:
> > http://wiki.xensource.com/xenwiki/XenParavirtOps
> > 
> > Redhat/Fedora pv_ops Xen kernel dom0 support status:
> > http://fedoraproject.org/wiki/Features/XenPvopsDom0
> 
> SLES 11 will include Linux 2.6.26 with Xen patches - packages should be
> available any day now from
> .  Is it
> possible that those patches will be usable in lenny, as I believe the
> kernel team expects to release with Linux 2.6.26?

dom0 looks currently out of reach,
what we have is the snapshotting features of 2.6.27 for x86_32.

see relevant posts of Ian Campbell on d-kernel


-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#436267: Firewire support in lenny

[maximilian attems]

[ stripping cc list to relevant bug report + devel for general info ]

On Tue, Feb 12, 2008 at 12:31:43PM +0100, Guus Sliepen wrote:
> On Tue, Feb 12, 2008 at 11:49:22AM +0100, maximilian attems wrote:
> 
> Given the pace of kernel releases, I do not believe 2.6.26 is possible
> for lenny, but 2.6.25 is possible, although I think it will only be
> released a month or two before the final freeze.

that discussion belongs to another thread, but don't be too pessimistic.
 
[snipp]
> libdc1394 2.0.1 is in unstable: http://packages.debian.org/libdc1394-22

cool.
sorry rmadison wasn't showing it to me yet.
 
> My IIDC cameras do not work correctly with a juju-enabled libdc1394
> 2.0.1. Furthermore, apart from coriander there are no applications that
> have migrated from libdc1394 v1 to v2.

even with 2.6.24-4 linux images?
please mention the uname of your tests
 
> > the progress of the juju stack is very nice, there are quite some
> > fixes queued for 2.6.25, we will make those snapshots available
> > soonest.
> 
> That is good to hear.

if you are on amd64 2.6.25-rc1-git2
-> http://photon.itp.tuwien.ac.at/~mattems/
will build i686 during day (takes much longer)

please if 2.6.24 has troubles feedback on that one.
 
> > if the regression list for 2.6.25 is still high we may reconsider
> > there to build the old stack with blacklisted modules.
> > that has always been our stated fallback position, currently in the
> > development phase we encourage testing of the newer stack
> > on latest linux-images.
> 
> I do not see why making the old stack available again, but blacklisted
> by default, discourages testing of the newer stack. If you have both
> available, then yes, users can switch to the new stack more easily, but
> at least they will still be using Debian kernel packages, and they can
> switch back to the juju stack just as well. If you do not make this
> option available, those who have problems with the new stack will have
> to compile their own kernels, and then they will not track the Debian
> kernel packages anymore.

you can't have both without blacklisting one otherwise udev loads
randomly from boot to boot other firewire stack. changing blacklist
files in /etc/modprobe.d is trivial.
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#436267: Firewire support in lenny

[maximilian attems]

On Tue, Feb 12, 2008 at 11:27:29AM +0100, Guus Sliepen wrote:
> On Sun, Feb 03, 2008 at 10:04:18AM +0100, Marc 'HE' Brockschmidt wrote:
> 
> > Early March 2008
> >   Very soft freeze
> [...]
> > Mid of July 2008
> >   Full freeze
> 
> I guess that means that lenny will be released with linux kernel
> 2.6.24.x. If that is so, then I kindly request that the debian kernel
> packages will be released with the stable Firewire stack modules
> compiled.

no certainly not, we haven't yet discussed the release kernel.
options are 2.6.25 or 2.6.26.
 
> The current kernel package mainainer(s) has (have) decided to disable
> the stable modules in favour of the new and experimental JuJu stack[0].
> The new stack has the advantage that is more secure and has a cleaner
> code base, but the drawback that a lot of devices and features are not
> yet supported. To summarise what the JuJu developers themselves say
> about the current state of the new stack[1]:

[snipp http://wiki.linux1394.org/JujuMigration ]
 
>  Regarding Linux 2.6.22...2.6.24, the best advice to Linux distributors
>  (kernel packagers) as well as to regular users is: Build only the old
>  IEEE 1394 drivers.

you omit the interesting next paragraph:
"Building the new drivers is only for advanced users (who for example
want the better speed of firewire-sbp2 relative to sbp2) - and for
distributors who know what is required in userspace to make use of the
new drivers and who can get bugfixes backported and rolled out quickly."

on the kernel side we do backport firewire patches.
for the userspace side i still see lack of action on libdc1394
"2008/01/05: The official version 2.0.0 has been released.
2008/01/05: A first set of fixes have been released (version 2.0.1)"

why is that not even in unstable/experimental?

> users it is better to load the modules for the JuJu stack by default.
> But for those people who need the stable stack to do work, the modules
> for the stable stack should be available. There is no reason not to
> build both stacks, they don't conflict with each other (except that only
> one works if you load both, of course).
> 
> I hope the kernel package maintainer(s) will make sure kernel packages
> with the stable modules available, but blacklisted by default, will
> enter testing soon, so that users of testing get a chance to test it
> before lenny is released.

the progress of the juju stack is very nice, there are quite some
fixes queued for 2.6.25, we will make those snapshots available
soonest.

if the regression list for 2.6.25 is still high we may reconsider
there to build the old stack with blacklisted modules.
that has always been our stated fallback position, currently in the
development phase we encourage testing of the newer stack
on latest linux-images.
 
 
> [0] http://bugs.debian.org/436267
> [1] http://wiki.linux1394.org/JujuMigration
> [2] http://en.wikipedia.org/wiki/FireWire#Security_issues


best regards

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Changing priority of selinux back to optional

[maximilian attems]

On Thu, Feb 07, 2008 at 01:34:11PM +0100, Stefano Zacchiroli wrote:
> On Wed, Feb 06, 2008 at 06:49:20PM +0100, maximilian attems wrote:
> > but currently willing to work on i'd nack fjp requests.
> > of course if no progress has been made in a month,
> > his request is more then reasonable.
> 
> I disagree that simply willingness can nack Frans' request.
> If the current situation is "bad", and I assume that trusting Frans'
> words, and it has been like that for long, then the request should be
> fulfilled now. Later on, if your willingness to work turns out in good
> result it can be reverted.

fjp didn't ask for it he send out a rfc and i only asked for 1 month time.

thanks

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Changing priority of selinux back to optional

[maximilian attems]

On Wed, 06 Feb 2008, Stefano Zacchiroli wrote:

> On Wed, Feb 06, 2008 at 12:27:45PM +0100, maximilian attems wrote:
> > I'd like to work on SELinux packages and bugs.
> 
> That's wonderful, thanks for your help offering!
> 
> Still, if I'm interpreting correctly Frans' and Erich's mails, the
> *current* status of SELinux in Debian is, erm, sub-optimal. So I think
> Frans' request of demoting selinux related stuff priority is entirely
> reasonable, isn't it?
> 
> So I presume you have nothing against actually changing the priority
> back to optional until you're working on the various fixes. Once the
> needed bug fixes and the pending package upgrades are in place, we can
> for sure promote again the priority. What do you think?

well i haven't heard yet back from Erich yet,
so I'm waiting his response.
cc'ing him diretly now ;)

but currently willing to work on i'd nack fjp requests.
of course if no progress has been made in a month,
his request is more then reasonable.
 
best regards

-- 
maks

ps keep me on response on cc, thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [RFC] Changing priority of selinux back to optional

[maximilian attems]

> The priority of selinux packages was changed from optional to standard, 
> fairly shortly before the release of Etch.
> 
> I propose to revert that change before Lenny. The basic reason is that
> the selinux packages have basically been unmaintained since the release
> of Etch.

I'd like to work on SELinux packages and bugs.
SELinux is doing great proactive security and I'd like
to help the Debian harden team. SELinux is currently the
most superior security policy and latest kernel see several
scalability fixes.

so asking if the SELinux team is ok with adding me as co-maintainer?
thanks Erich for your concise posting on where the work needs
to be picked up!

best regards

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

['maximilian attems']

Hello May!

On Fri, Feb 01, 2008 at 07:38:03AM -0800, May Hwang wrote:
> 
> Thanks for the update. So this etch-n-half is the next Debian release, which
> already have HighPoint driver included? When etch-n-half will official hit
> the market?  

etch-n-half is the planed Linux kernel upgrade for the Etch Debian
distribution, roughly after 1/2 of it's lifetime, for more info on it
see http://wiki.debian.org/EtchAndAHalf

there is no hard date out yet, but you get an educated guess from
http://lists.debian.org/debian-kernel/2008/01/msg00217.html
http://lists.debian.org/debian-kernel/2008/01/msg00697.html
(due to beta1 debian-installer and etch+half coupling)
 
> Best Regards,
>  
> May Hwang

happy weekend.


-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

['maximilian attems']

hello May,

On Fri, Feb 01, 2008 at 08:31:29AM -0800, May Hwang wrote:
> 
> Thanks! Is this the first time you head about HighPoint? We used to only
> offer Cost effective RAID controller or if refer to Linux community these
> are the Fake RAID category. 

not the first time,
i had followed the hptiop submission upstream for the 2.6.18 time
frame, but yes i haven't encountered the hardware directly.
 
> My SI customer suggest we should educate Linux distributions or ask advice
> from Linux distribution developer where can we update our hardware RAID
> product information, it kind of letting Linux community knows HighPoint
> products now its GPL licensed and it is hardware RAID controller.
> 
> Any ideas?

you seem to have already generated quite some good press on the most
important German tech press.

dell has a community centre where customers can generated input,
try to consider such. the dell idea storm cite generated quite
some participation also people where very happy that they got
listened to so new laptop models coming out with Linux.

otherwise a tech show off of the capabilities of your product
in terms of performance benchmarks, power efficiency (powertop)

your worst defficiency currently seems that a quick top ten
google of "highpoint gpl" doesn't direct me anywhere near to
a cool site of yours. also "highpoint linux" lands on a faq
as top one that is quite terse.

hope that helps.
 
> Best Regards,
>  
> May Hwang

good success + warm greetings of cold vienna

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

['maximilian attems']

On Fri, Feb 01, 2008 at 09:48:42AM -0800, May Hwang wrote:
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=tree;f=dr
> ivers/scsi;h=03a18a7adc45ab39658ac83cf90e56e43598ee3e;hb=HEAD.

i know if you followed the link to the kernel svn change,
you would have seen that the commit was directly taken out of git.
 
> Meanwhile, I really would like to know more about the "back porting" our GPL
> driver into current stable Debian distribution?
> 
> I'm sorry, What is snapshot sid builds?  

please read the docs you are pointed to
-> wiki.debian.org/DebianKernel
there you have the sid daily builds,
it would be really appreciated that you test boot
such a kernel and show us dmesg.

 
weekend starting, best regards

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be IncludeInDebian Distribution

[maximilian attems]

On Fri, Feb 01, 2008 at 06:29:48PM +0100, Josselin Mouette wrote:
> Le vendredi 01 février 2008 à 07:38 -0800, May Hwang a écrit :
> > Dear Maks,
> > 
> > Thanks for the update. So this etch-n-half is the next Debian release, which
> > already have HighPoint driver included? When etch-n-half will official hit
> > the market?  
> 
> This release will include whatever has been included in the upstream
> kernel at version 2.6.24. AIUI, if your driver has been included only in
> the 2.6.25 branch, it will probably not be included.

indeed 2.6.24 Debian deviates only slightly from upstream,
some added patches, GPL enforcement, but we always consider driver
backports to our stable kernel and have a history to do such.

also joss is not a member of the etch+half pushing teams
aka the debian kernel, installer and security teams.

so be assured that your latest driver landed.
i haven't heard yet from you May that you would test our
tomorrows snapshot sid builds next week?

bon weekend again

-- 
maks
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be Include InDebian Distribution

[maximilian attems]

On Mon, 28 Jan 2008, May Hwang wrote:

> 
> Thanks, please help include our driver in etch-n-half.
> 

forgot to mention that your posting gave you good german tech press
-> http://www.heise.de/newsticker/meldung/102841


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: HighPoint- GPL Licensed Controller wants To be Include InDebian Distribution

[maximilian attems]

Dear May,

On Mon, 28 Jan 2008, May Hwang wrote:

> Dear Margarita,
> 
> Thanks, please help include our driver in etch-n-half.
> 
> Please find Latest HighPoint Source files in 2.6.24 are located at:
> drivers\scsi\hptiop.c
> drivers\scsi\hptiop.h
> Documentation\scsi\hptiop.txt
> 
> 2.6.24-rc8-mm1 built-in it, you can get it from www.kernel.org.

as linus already merged the driver update.
just commited the patch from latest git into our tree for the
2.6.24 etch+half update kernel:
http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2008-February/009187.html

> FYI, HighPoint do have validation program with most of main vendors in the
> market- Seagate, Western Digital, Hitachi, Supermicro, Tyan, Asus,
> clustersoftware vendor, Storage software vendors, AIC, CI-design and etc. 
> 
> In regards of source package guideline, I will check with my firmware group
> if they have any questions.
> 
> Thanks for the quick response!

thanks for bringing the issue to our attention.
 
> Best Regards,
>  
> May Hwang
>  
> HighPoint Technologies,Inc.
>  
> Tel:408-240-6118/6112
> Fax-408-942-5800
>  
> www.highpoint-tech.com
> www.hptmac.com
>  
> Distribution Partners: ASI, BellMicro, D&H, Malabs
> "RocketRAID - Terabyte Storage Technologies"

for more information about the debian kernel see
http://wiki.debian.org/DebianKernel
(commit list, team, general docs, ..)

it would be cool if you would test tomorrows sid snapshot builds?
see aboves for the apt lines.


best regards

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Heads up on initramfs-tools dev

[maximilian attems]

MODULES=dep


  The size of the generated initramfs of initramfs-tools
  in the case of MODULES=dep improved since 0.90a version.
  i'd like to get more tester feedback on that setting.
  -> /etc/initramfs-tools/initramfs.conf
  
  WARNING:
  The ide subsys has a funky /sys usage where the sysfs
  modules string does not match the modules name. There the
  sysfs walk is presumed to fail (PIIX_IDE != piix).
  This will go away soon after the migration to pata.

  For initramfs debugging see
  http://wiki.debian.org/InitramfsDebug 


BUSYBOX=n
-

  This setting boots fine since 0.90a and klibc 1.5.6
  on /dev/sdaX root (UUID, LABEL usage included).
  0.91 moves busybox from Depends to Recommends.
  allowing package enforced BUSYBOX=n
  keep in mind that in the case of a boot failure
  your recovery tools in that situation will be
  very limited to echo, cat, dmesg, uname, fstype
  (see ls /usr/lib/klibc/bin/ ).

  I'd ask the d-i folks to queue busybox before i-t
  in the base install as it is needed for any but
  unusual installations. also i'll send patches out
  to different initramfs boot script to enforce
  BUSYBOX=y as they might rely on busybox tools
  (sed, awk, grep, tr, ..).


klibc

  
  Next steps on a real small initramfs for embedded
  usage is udev-klibc (compiles and boots fine) and
  a m-i-t against klibc.

  klibc got a stdio branch so if others want to play^W
  compile against klibc that might be the better
  start to hack on (lvm2, mdadm or even busybox comes
  to the mind) just install libklic-dev and use
  make CC=klcc

  hpa is active, patches are quickly reviewed and
  merged upstream.
  git clone git://git.kernel.org/pub/scm/libs/klibc/klibc.git
  Mailing list: http://www.zytor.com/mailman/listinfo/klibc

  The klibc linux-libc-dev build-dep change went well
  (quickly fixed mips+ia64), but gcc-4.2 seems to hit
  on sparc.  that will need attention by sparc porters
  once the kernel sparc issues are solved. #440721


initramfs races
---

  Push usage of scsi_wait_scan upstream (thanks a lot
  willy for the work). already implemented in qlogic,
  aic94xx, lpfc and fusion. The udev boot script just
  needs to modprobe it. Patches for ata aka sata and
  pata are in preparation.

  The suse bootscripts wait up to some seconds for
  /dev/mapper/control to appear. that seems sensible
  and easy to do in the debian lvm2 boot script too.


dkt
---

  Once dkt [1] is in place linux-images will ship
  parts of the modules prebuild as initramfs in order
  to reduce build time of the default initramfs.
  Also grub2 allows multiple initramfs files usage.

  The dkt will also allow to remove the corresponding
  initramfs sha1sum's in /var/lib/initramfs-tools on
  linux-image removal.


git repo

  
  initramfs repository moved some time ago to git [2]:
  git clone git://git.debian.org/git/kernel/initramfs-tools.git

  
  A special thanks goes to mika for test coverage [3]
  on grml.


happy hacking

-- 
maks

[1] http://multibuild.org/documentation/dkt
[2] http://www.itp.tuwien.ac.at/~mattems/blog/2007/04/10#bzr_to_git
[3] http://www.mail-archive.com/[EMAIL PROTECTED]/msg01388.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: fstab update for persistent device names

[maximilian attems]

On Fri, Jul 27, 2007 at 09:23:37AM +0200, Andreas Barth wrote:
> * Bastian Blank ([EMAIL PROTECTED]) [070726 11:40]:
> > For the libata-pata support we need to change fstab on several arches to
> > not break all systems which uses them.
> > 
> > We need to decide which arches needs this rewrite now and which value
> > should be filed in.
> 
> I'd like to ask you to postpone such changes until we split the
> etch+.5-kernel off (because we don't want to change the fstab on the new
> kernel, but on the upgrade from etch to lenny).

i don't see this correlation as it is easy to revert back to old IDE
instead of PATA for the etch kernel.
according to dannf the target kernel wouldn't be 2.6.23 (fedora 8)
but a later kernel when oldstable no longer receives security
support. so that would mean scheduling that change very late in the
release process of lenny!?
 
> (And, BTW, I don't think this is a kernel-only topic, so setting Cc
> accordingly).

agreed it's a userspace trouble, so leave it to the user :P

no seriously the debian-installer team needs to be too in the loop
as they would need to sync the decision too for newly installed boxes.
 
-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: initramfs-tools postinst causes system inconsistency?

[maximilian attems]

i'd appreciate if you post such questions to the corresponding
development mailing list which is debian-kernel for initramfs
questions. 
thanks

> Current pratice is to only call `update-initramfs -u', that is, to only
> update the most recent initramfs. This however will break older
> initramfses (I have had bugreports). Now I plan to switch to running
> with '-k all' (all initramfses), but this of course will also
> influence=20 the packages that ran with '-u' only.

afaik uswsusp does not support full > 2.6.15 range,
so better stay on the safe side.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: (proposed) Mass bug filing?for debconf "abuse" by using low|medium priority debconf notes?

[maximilian attems]

> Debian logcheck Team 
>  logcheck-database -- config:17 logcheck-database/standard-rename-note

removed in svn, will disappear on next upload.

> Debian logcheck Team 
>  logcheck -- config:14 logcheck/install-note
>  logcheck -- config:17 logcheck/changes

first gone, second added retroactively to NEWS.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFC: swap on a LVM volume in debian-installer

[maximilian attems]

On Thu, Jun 22, 2006 at 10:46:59PM +0200, David Härdeman wrote:
> 
> I'm currently considering whether to change partman-auto-lvm so that the 
> swap partition is created as a lvm lv rather than a separate partition, 
> and I'd like to ask for some comments and feedback before doing so.

ack. cool, already using since long, as swap on lvm allows much more
flexibility.

 
> o suspend-to-disk
> There have been concerns that suspend/resume may not work with swap on a 
> lvm volume.
> 
> Using initramfs-tools, it seems perfectly possible to resume from a swap 
> partition on lvm (I do so daily). I am not sure whether yaird supports 
> this feature.

works right now fine on initramfs-tools.
thanks for addressing the trouble of multiple volume groups.
 
good work. :)

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian

[maximilian attems]

On Tue, 28 Feb 2006, Steve Langasek wrote:

> On Tue, Feb 28, 2006 at 09:59:17AM +0100, maximilian attems wrote:

> 
> > as the xen userspace is tightly integrated to the xen kernel,
> > it makes a lot of sense to release both in the same run.
> 
> But it doesn't make sense to release them both as part of the same source
> package,

sure that was never proposed.

> and it doesn't necessarily make sense to keep them in the same svn
> repo.  Can you explain why it's better for the xen userspace/hypervisor
> packages to be kept under the aegis of the kernel team, instead of for
> Bastian (and other interested developers) to join the pkg-xen team?  Is
> there really so much more interest in the xen-tools among the members of the
> kernel team than among the, er, Xen team?

yes we want to release etch with Xen!

not like sarge were uml received not the love it should have received.
the 3.0 hypervisor is communicating through procfs. lkml patches have
shown sysfs patches trying to reimpleiment procfs code and more recently
purer sysfs interfaces.  i expect some more churns in that direction,
so a tight cooperation is needed. 

the separted repo and lists to track are at this stage more a nuisance
than a help.
 
> Holding all the members of the pkg-xen team responsible for what one of
> their fellows has written in his blog would be petty and immature, and would
> not exactly be the kind of encouragement one would hope to see from the
> kernel team seeking the input of others interested in Xen packaging.

i'm relying on xen at my work place. i'm very interested in xen packaging.
as it allows me to easily test initramfs-tools on various setups.
firing up roots on lvm2, md0 or whatever..
looking forward to switch from handbuild rsynced chroots to fine debs ;)

so the xen team needs either to come with us or allow more of us to join.
also basing their repo on waldi's work.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian

[maximilian attems]

On Mon, 27 Feb 2006, Guido Trotter wrote:

> 
> Absolutely true! The current xen team is fully agrees on this position!
> 
> Guido

xen 3.0 is out since the 6th of december!
so it has seen considerable amount of production use since.
as the xen userspace is tightly integrated to the xen kernel,
it makes a lot of sense to release both in the same run.

the debian kernel team has always been open to valuable input.
beeing just annoyed and threatening to bypass on weblog doesn't
put your team on a good light.

waldi is packaging the xen kernel in the linux-2.6 way.
i'm confident that those packages get further enhanced.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Maximilian Attems]

On Wed, Jan 04, 2006 at 01:51:17PM +0100, Gabor Gombas wrote:

> 
> Packaging at least -rc kernels for unstable might be a good idea for
> Debian too. That would provide more testing coverage for -rc releases,
> and this is what upstream needs the most.

the -rc kernels are build in experimental, staging area for unstable
and without any potential d-i breakage.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: bits from the release team

[Maximilian Attems]

On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote:
> On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
> 
> Why do you put the kernel together with the essential toolchain freeze, it
> should be together with the rest of base, i believe.

the kernel is an essential piece of our release,
makes sense to have it in tune with everchanging userspace interfaces
(alsa, udev to name a few).
 
> > N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> > e.g. cdbs)
> > N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> > freeze, d-i RC]
> > N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
> 
> We will have a kernel which is outdated by two versions at release time with
> this plan, since there are about 1 kernel upstream release every 2 month.

we had the chance for sarge, but we weren't ready.
for etch we will work for our best to be ready.

please don't rush out such mails without consensual position.

-- 
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GCC version change / C++ ABI change

[maximilian attems]

On Mon, 04 Jul 2005, Marc Haber wrote:

> On Mon, Jul 04, 2005 at 11:12:21AM +0200, Thiemo Seufer wrote:
> > Most kernel hackers don't care that much about 2.4 any more.
> 
> This is of course one of the reasons why users feel left alone by the
> kernel developers.

2.2 went also in deep freeze for 2.4?
what are you whining about - an x86 only kernel,
that needed to be heavily patched by each distro to get usable?
 
--
maks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312563: ITP: klibc -- minimal libc subset

[maximilian attems]

Package: wnpp
Severity: wishlist
Owner: maximilian attems <[EMAIL PROTECTED]>

* Package name: klibc
  Version : 1.0.14
  Upstream Author : H. Peter Anvin <[EMAIL PROTECTED]>
* URL : http://www.kernel.org/pub/linux/libs/klibc/
* License : GPL/BSD
  Description : minimal libc subset

minimal libc subset for use with initramfs and udev.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.12-rc6
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#312561: ITP: initramfs -- tools to create an initramfs

[maximilian attems]

Package: wnpp
Severity: wishlist
Owner: maximilian attems <[EMAIL PROTECTED]>

* Package name: initramfs
  Version : 0.7
  Upstream Author : Jeff Bailey <[EMAIL PROTECTED]>
* URL : http://www.ubuntulinux.org/wiki/Initramfs
* License : PUBLIC DOMAIN
  Description : tools for generating an initramfs

This package contains tools to create an initramfs archive for prepackaged 
Linux kernel. The initramfs is an cpio archive. At boot time, the kernel 
unpacks that archive, mounts and uses it as initial root filesystem.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.12-rc6
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]