что-то тихо вокруг. Я туда попал? :) -- С уважением Виктор В Исмакаев ivv@altlinux.ru
On Fri, 4 Apr 2003 10:12:55 +0600
Victor V Ismakaev <ivv@altlinux.ru> wrote:
> что-то тихо вокруг.
> Я туда попал? :)
- Шеф, я вас вижу! =)
--
Баталов Григорий,
системный администратор
ОАО "Ковдорский ГОК"
4 Апрель 2003 10:20, Grigory Batalov написал:
> On Fri, 4 Apr 2003 10:12:55 +0600
>
> Victor V Ismakaev <ivv@altlinux.ru> wrote:
> > что-то тихо вокруг.
> > Я туда попал? :)
>
> - Шеф, я вас вижу! =)
Ага. Значит я по адресу :)
Хотелось бы узнать текущее положение в наших ядрах патча от Инго Молнара O(1),
preemtible-patch и low-latency patch.
--
С уважением
Виктор В Исмакаев
ivv@altlinux.ru
Victor V Ismakaev <ivv@altlinux.ru> writes: > Ага. Значит я по адресу :) > Хотелось бы узнать текущее положение в наших ядрах патча от Инго Молнара O(1), В vanilla в daedalus их, как видите, нет. В первом релизе, который будет выложен, -- тоже не будет. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite!
[-- Attachment #1: signed data --] [-- Type: text/plain, Size: 1140 bytes --] Всем привет! Народ, я одного не понимаю, как такие пакеты вообще в сизиф пропускаются? Стоит, к примеру, мне или кому-там допустить ошибку - сразу поднимаются крики. А тут блин ни слова никто не сказал. пакет kernel-build-tools: Не описан макрос %kgcc Не описан макрос %base_arch Путь к директории патчей (%patches_dir) описан неверно (%buildroot/%_usrsrc/kernel/patches вместо просто %_usrsrc/kernel/patches) пакеты c патчами и исходниками ядра: не описаны права к файлам в каталоге /usr/src/kernel. (%attr needed?) из-за чего я при сборке ядра получаю: Applying patch bootsplash-3.0.7-2.4.20-vanilla.diff ... + cat /usr/src/kernel/patches/kernel-feat-drivers-video-splash/bootsplash-3.0.7-2.4.20-vanilla.diff cat: /usr/src/kernel/patches/kernel-feat-drivers-video-splash/bootsplash-3.0.7-2.4.20-vanilla.diff: Permission denied в результате я только и делаю, что правлю правлю и правлю спеки вместо того, чтобы уже заливать ядро. Пожалуйста исправьте такое положение. -- With Best Regards, Albert R. Valiev ------------------------------------ ALT Linux Team [www.altlinux.ru] KDE Development Team [www.kde.org] [-- Attachment #2: signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Hi all! Смотрю, тут тишина? Или у меня фильтры неправильно работают? Как правильно составить заявку на добавление патчей в ядро? У нас(alt kernel), как и у многих других, кривая реализация mppe для ppp. Патчи давно существуют, нужно только включить, там десять строк.
29 Май 2003 19:42, Andrew Kornilov написал:
> Hi all!
>
> Смотрю, тут тишина? Или у меня фильтры неправильно работают? Как
> правильно составить заявку на добавление патчей в ядро? У нас(alt
> kernel), как и у многих других, кривая реализация mppe для ppp. Патчи
> давно существуют, нужно только включить, там десять строк.
Имеете ввиду ppp-2.4.1 или ppp-2.4.2?
--
С уважением
Виктор В Исмакаев
ivv@altlinux.ru
>>>>> "AF" == Anton Farygin writes: AF> Ed V. Bartosh пишет: >> Добрый день. Обращаюсь к мэйнтейнерам ядерных пакетов: А как кто >> синхронизируется с тем, что делают другие ? Только по постингам >> сюда или еще как ? Может все-таки CVS заведем для спеков на >> kernel- пакеты ? И свалку вновь собраных пакетов ? В Сизиф >> слишком долго все это ползет, а работа по характеру коллективная >> и изменения желательно иметь как можно раньше. И не только нам. AF> Да, CVS, CVS !!! AF> Пересборку смогу обеспечить в BTE. Пересборку всего ? Отлично ! А место для заливки/выкачивания пакетов обеспечишь ? Ну и CVS для спеков заодно :) Если бы это еще и автоматизировать, то было бы совсем хорошо. Я имею в виду автоматическую пересборку измененных пакетов и всего, что зависит от них. И, если все собралось, то отправку в Сизиф. Таким образом мы в Сизифе будем держать заведомо собирающийся набор пакетов. >> В идеале, конечно, хотелось бы иметь место, в котором >> пересобираются все ядра и модули после изменения общих пакетов, >> для того, чтобы не ломать собираемость в Сизифе. После такой >> пересборки все можно класть в Сизиф. Кто что скажет ? >> AF> Я - только за. Совсем не могу ничего делать без CVS ;-( Вот именно. У меня уже полная каша с этой синхронизацией. CVS нужен и чем быстрее, тем лучше. -- Best regards, Ed V. Bartosh X-Mailer: Gnus v5.10.2/XEmacs 21.4 - "Portable Code" >From ed@altlinux.ru Tue Jun 24 21:36:48 2003 Return-Path: <ed@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 67EC849A14 for <devel-kernel@lrn.ru>; Tue, 24 Jun 2003 21:36:48 +0400 (MSD) Received: from mail.belcaf.minsk.by (mail.sam-solutions.net [217.21.35.41]) by master.altlinux.ru (Postfix) with ESMTP id 87F7AE31CF for <devel-kernel@altlinux.ru>; Tue, 24 Jun 2003 21:36:39 +0400 (MSD) Received: from pc213.sam-solutions.net ([192.168.111.243]) by mail.belcaf.minsk.by (MTA 4.15) with ESMTP id HGZY9100.7DO for <devel-kernel@altlinux.ru>; Tue, 24 Jun 2003 20:36:37 +0300 Received: from pc213.sam-solutions.net (localhost.localdomain [127.0.0.1]) h5OGZx3x023908 for <devel-kernel@altlinux.ru>; Tue, 24 Jun 2003 20:35:59 +0400 Received: (from ed@localhost) by pc213.sam-solutions.net (8.12.9/8.12.6/Submit) id h5OGZx9I023907; Tue, 24 Jun 2003 20:35:59 +0400 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Tue, 24 Jun 2003 20:35:58 +0400 Message-ID: <m3of0n1lht.fsf@altlinux.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Subject: [d-kernel] fix for kernel-image* specs X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 24 Jun 2003 17:36:48 -0000 Hi, All Никто не замечал, что текущие ядра не удаляются ? rpm -e kernel-image-std-up error: execution of %preun scriptlet from kernel-image-std-up-2.4.21rel-alt1 failed, exit status 1 Вот фикс, нужно бы все спеки, где еще не пофикшено, подправить. --- cvs/classic/packages/kernel-image-aw-up~ 2003-06-24 20:21:34 +0400 +++ cvs/classic/packages/kernel-image-aw-up 2003-06-24 20:31:39 +0400 @@ -180,7 +183,7 @@ BUILD=/lib/modules/%kversion-%flavour-%krelease/build -[[ -n $REMOVE ]] && /sbin/installkernel -a -R -c %kversion-%flavour-%krelease +[[ -z $REMOVE ]] || /sbin/installkernel -a -R -c %kversion-%flavour-%krelease %postun -- Best regards, Ed V. Bartosh X-Mailer: Gnus v5.10.2/XEmacs 21.4 - "Portable Code" >From andrei@lrn.ru Tue Jun 24 21:45:39 2003 Return-Path: <andrei@lrn.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id E1AEA4932F for <devel-kernel@lrn.ru>; Tue, 24 Jun 2003 21:45:39 +0400 (MSD) Received: from smtp.tvcom.ru (smtp.tvcom.ru [80.246.64.4]) by master.altlinux.ru (Postfix) with ESMTP id D3754E31CF for <devel-kernel@altlinux.ru>; Tue, 24 Jun 2003 21:45:39 +0400 (MSD) Received: by smtp.tvcom.ru (Postfix, from userid 1004) id 6E3A010E6B9; Tue, 24 Jun 2003 21:45:39 +0400 (MSD) Received: from ok-cmp.lnet (ppp-367.tvcom.ru [80.246.74.196]) by smtp.tvcom.ru (Postfix) with SMTP id 82F7610DD78 for <devel-kernel@altlinux.ru>; Tue, 24 Jun 2003 21:45:37 +0400 (MSD) Date: Tue, 24 Jun 2003 21:45:19 +0400 From: Andrey Astafiev <andrei@lrn.ru> To: devel-kernel@altlinux.ru Message-Id: <20030624214519.66e68c6b.andrei@lrn.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: [d-kernel] [FR]: mount rainier support X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 24 Jun 2003 17:45:40 -0000 Кто-нибудь из разработчиков пакетов с ядрами собирается включить в своё детище патч Mount Rainier? Патч можно найти у Jens Axboe на kernel.org и на atmsk.ru я давно выкладывал информацию о том, что это такое. Очень бы хотело такое для десктопного ядра. У меня остались такие ссылки, может что-нибудь ещё работает http://www.nix.ru/news/articles/reviews/cd/mtRainier.html http://marc.theaimsgroup.com/?l=linux-kernel&w=2&r=1&s=rainier&q=b http://www.atmsk.ru/viewtopic.php?p=484 -- Andrey Astafiev andrei (at) altlinux (d0t) ru >From vsu@altlinux.ru Wed Jun 25 17:11:28 2003 Return-Path: <vsu@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 0D8BC49B46 for <devel-kernel@lrn.ru>; Wed, 25 Jun 2003 17:11:25 +0400 (MSD) Received: from mail.mivlgu.ru (mivlgu.ru [81.18.140.87]) by master.altlinux.ru (Postfix) with ESMTP id 799E5E31D4 for <devel-kernel@altlinux.ru>; Wed, 25 Jun 2003 17:11:24 +0400 (MSD) Received: by mail.mivlgu.ru (Postfix, from userid 112) id 3AE3C81AB9; Wed, 25 Jun 2003 17:02:57 +0400 (MSD) Received: from vcserver.mivlgu.local (vcserver.mivlgu.local [192.168.1.251]) by mail.mivlgu.ru (Postfix) with SMTP id BEAD281A42; Wed, 25 Jun 2003 17:02:51 +0400 (MSD) Date: Wed, 25 Jun 2003 17:02:47 +0400 From: Sergey Vlasov <vsu@altlinux.ru> To: devel-kernel <devel-kernel@altlinux.ru> Message-Id: <20030625170247.22d5a3f7.vsu@altlinux.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.H,mH9H?_L608w2" Subject: [d-kernel] kernel-feat-evms non-BTE build problem X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Wed, 25 Jun 2003 13:11:29 -0000 --=.H,mH9H?_L608w2 Content-Type: multipart/mixed; boundary="Multipart_Wed__25_Jun_2003_17:02:47_+0400_084ca3f0" --Multipart_Wed__25_Jun_2003_17:02:47_+0400_084ca3f0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 SGVsbG8hDQoNCvPP19PFzSDawcLZzCDQ0s8g1M8gwsXaz8LSwdrJxSwgy8/Uz9LPxSDRIM/CzsHS 1dbJzCDXDQprZXJuZWwtZmVhdC1ldm1zLnNwZWM6DQoNCiVfX2NwIC1hICVfc291cmNlZGlyLyog JXtwYXRjaGVzX2Rpcn0vJXtwYXRjaF9uYW1lfS8NCg0K8M8tzc/FzdUsINTByyDOxczY2tEuIPDP ztHUzs8sIN7UzyDXIEJURSDc1M/UINDBy8XUINPPwsnSwcXU09EgwsXaDQrQ0s/CzMXNLCDQz9PL z8zYy9Ug1yAlX3NvdXJjZWRpciDeydPUzywgzs8g0NLJIM/C2d7Oz8og08LP0svFIMLF2iBCVEUN CtTVxMEgzsHCydfBxdTT0SDeo9LUINrOwcXUIN7Uzy4NCg0K8SDQz9DSz8LP18HMINrB09XO1dTY INPCz9LL1SDT0MnTy8EgztXWztnIIMbByszP1yDXIM3By9LP09kgLSDULsUuDQrXzcXT1M8gU291 cmNlTjogRklMRSDO1dbOzyDQydPB1NggJXNvdXJjZSBOIEZJTEUuIPrBz8TOzyDawc3FzsnMICVf X2NwDQotYSDOwSAlX19pbnN0YWxsIC1wIC1tNjQ0Lg0KDQr0wcvPyiAuc3BlYyDHz8TJ1NPRPw0K DQotLSANClNlcmdleSBWbGFzb3YNCg== --Multipart_Wed__25_Jun_2003_17:02:47_+0400_084ca3f0 Content-Type: application/octet-stream; name="kernel-feat-evms.spec" Content-Disposition: attachment; filename="kernel-feat-evms.spec" Content-Transfer-Encoding: base64 IyAtKi0gcnBtLXNwZWMgLSotCiMgJElkOiBrZXJuZWwtZmVhdC1ldm1zLHYgMS42IDIwMDMvMDYv MDYgMTI6MzU6NTMgZWQgRXhwICQKIyMKJWRlZmluZSAgcGF0Y2hfbmFtZSBrZXJuZWwtZmVhdC1l dm1zCgpOYW1lOiAlcGF0Y2hfbmFtZQpWZXJzaW9uOiAyLjAuMQpSZWxlYXNlOiBhbHQyCgpTdW1t YXJ5OiAlcGF0Y2hfbmFtZSBrZXJuZWwgcGF0Y2ggLSBFbnRlcnByaXNlIFZvbHVtZSBNYW5hZ2Vy IFN5c3RlbQpMaWNlbnNlOiBHUEwKR3JvdXA6IERldmVsb3BtZW50L090aGVyClVybDogaHR0cDov L2V2bXMuc291cmNlZm9yZ2UubmV0LwpQYWNrYWdlcjogS2VybmVsIE1haW50YWluZXJzIFRlYW0g PGtlcm5lbEBwYWNrYWdlcy5hbHRsaW51eC5vcmc+CgolZ2xvYmFsIF9zb3VyY2VzX2xpc3QgJW5p bAolZGVmaW5lIHNvdXJjZSgpIFNvdXJjZSUxOiAlMiAlZ2xvYmFsIF9zb3VyY2VzX2xpc3QgJV9z b3VyY2VzX2xpc3QgJTIKCiVzb3VyY2UgMSAwMDAwMS1hbHQucGF0Y2gKJXNvdXJjZSAyIDAwMDAy LnBhdGNoCiVzb3VyY2UgMyAwMDAwMy5wYXRjaAolc291cmNlIDQgMDAwMDQucGF0Y2gKJXNvdXJj ZSA1IDAwMDA1LnBhdGNoCiVzb3VyY2UgNiAwMDAwNi5wYXRjaAolc291cmNlIDcgMDAwMDcucGF0 Y2gKJXNvdXJjZSA4IDAwMDA4LnBhdGNoCiVzb3VyY2UgOSAwMDAwOS5wYXRjaAolc291cmNlIDEw IDAwMDEwLnBhdGNoCiVzb3VyY2UgMTEgMDAwMTEucGF0Y2gKJXNvdXJjZSAxMiAwMDAxMi5wYXRj aAolc291cmNlIDEzIDAwMDEzLnBhdGNoCiVzb3VyY2UgMTQgMDAwMTQucGF0Y2gKJXNvdXJjZSAx NSAwMDAxNS5wYXRjaAolc291cmNlIDE2IDAwMDE2LnBhdGNoCiVzb3VyY2UgMTcgMDAwMTcucGF0 Y2gKJXNvdXJjZSAxOCAwMDAxOC5wYXRjaAolc291cmNlIDE5IDAwMDE5LnBhdGNoCiVzb3VyY2Ug MjAgMDAwMjAucGF0Y2gKJXNvdXJjZSAyMSAwMDAyMS5wYXRjaAolc291cmNlIDIyIDAwMDIyLnBh dGNoCiVzb3VyY2UgMjMgMDAwMjMucGF0Y2gKJXNvdXJjZSAyNCAwMDAyNC5wYXRjaAolc291cmNl IDI1IDAwMDI1LnBhdGNoCiVzb3VyY2UgMjYgMDAwMjYucGF0Y2gKJXNvdXJjZSAyNyAwMDAyNy5w YXRjaAolc291cmNlIDI4IDAwMDI4LnBhdGNoCiVzb3VyY2UgMjkgMDAwMjkucGF0Y2gKJXNvdXJj ZSAzMCAwMDAzMC5wYXRjaAolc291cmNlIDMxIDAwMDMxLnBhdGNoCiVzb3VyY2UgMzIgMDAwMzIu cGF0Y2gKJXNvdXJjZSAzMyAwMDAzMy5wYXRjaAolc291cmNlIDM0IDAwMDM0LnBhdGNoCiVzb3Vy Y2UgMzUgMDAwMzUucGF0Y2gKJXNvdXJjZSAzNiAwMDAzNi5wYXRjaAolc291cmNlIDM3IDAwMDM3 LnBhdGNoCiVzb3VyY2UgMzggMDAwMzgucGF0Y2gKJXNvdXJjZSAzOSAwMDAzOS5wYXRjaAolc291 cmNlIDQwIDAwMDQwLnBhdGNoCiVzb3VyY2UgNDEgMDAwNDEucGF0Y2gKJXNvdXJjZSA0MiAwMDA0 Mi5wYXRjaAolc291cmNlIDQzIDAwMDQzLnBhdGNoCiVzb3VyY2UgNDQgMDAwNDQucGF0Y2gKJXNv dXJjZSA0NSAwMDA0NS5wYXRjaAolc291cmNlIDQ2IDAwMDQ2LnBhdGNoCiVzb3VyY2UgNDcgMDAw NDcucGF0Y2gKJXNvdXJjZSA0OCAwMDA0OC5wYXRjaAolc291cmNlIDQ5IDAwMDQ5LnBhdGNoCiVz b3VyY2UgNTAgMDAwNTAucGF0Y2gKJXNvdXJjZSA1MSAwMDA1MS1hbHQucGF0Y2gKJXNvdXJjZSA1 MiAwMDA1Mi5wYXRjaAolc291cmNlIDUzIDAwMDUzLnBhdGNoCiVzb3VyY2UgNTQgMDAwNTQucGF0 Y2gKJXNvdXJjZSA1NSAwMDA1NS5wYXRjaAolc291cmNlIDU2IDAwMDU2LnBhdGNoCiVzb3VyY2Ug NTcgMDAwNTcucGF0Y2gKJXNvdXJjZSA1OCAxLWRtLWJhc2UucGF0Y2gKJXNvdXJjZSA1OSAyLXN5 bmNpby5wYXRjaAolc291cmNlIDYwIDMtZG0tYmJyLnBhdGNoCiVzb3VyY2UgNjEgNC1kbS1zcGFy c2UucGF0Y2gKJXNvdXJjZSA2MiA3LXZmcy1sb2NrLWFsdC5wYXRjaAolc291cmNlIDYzIGxpbnV4 LTIuNC1ldm1zLTIuMC4wLXRvLTIuMC4xLnBhdGNoCgpCdWlsZEFyY2g6IG5vYXJjaApCdWlsZFBy ZVJlcToga2VybmVsLWJ1aWxkLXRvb2xzCgolZGVzY3JpcHRpb24KVGhpcyBwYXRjaCBhZGRzIHN1 cHBvcnQgZm9yIEVWTVMsIHRoZSBFbnRlcnByaXNlIFZvbHVtZSBNYW5hZ2VyIFN5c3RlbS4KCiVp bnN0YWxsCgolX19ta2Rpcl9wICV7cGF0Y2hlc19kaXJ9LyV7cGF0Y2hfbmFtZX0vCmZvciBmaWxl IGluICVfc291cmNlc19saXN0OyBkbwoJJV9fY3AgLWEgJV9zb3VyY2VkaXIvIiRmaWxlIiAle3Bh dGNoZXNfZGlyfS8le3BhdGNoX25hbWV9Lwpkb25lCgolZmlsZXMKJV91c3JzcmMvKgoKJWNoYW5n ZWxvZwoqIFNhdCBKdW4gMDcgMjAwMyBTZXJnZXkgVmxhc292IDx2c3VAYWx0bGludXgucnU+IDIu MC4xLWFsdDIKLSBGaXhlZCBwcm9ibGVtcyB3aXRoIG5vbi1CVEUgYnVpbGQgKCUlX3NvdXJjZWRp ci8qIHBpY2tlZCB1cCByYW5kb20gZ2FyYmFnZQogIGZyb20gdGhhdCBkaXJlY3RvcnkpLgoKKiBU aHUgTWF5IDIyIDIwMDMgRWQgVi4gQmFydG9zaCA8ZWRAc2FtLXNvbHV0aW9ucy5uZXQ+IDIuMC4x LWFsdDEKLSBVcGRhdGVkIHRvIGV2bXMgMi4wLjEKCiogV2VkIE1heSAxNCAyMDAzIEVkIFYuIEJh cnRvc2ggPGVkQHNhbS1zb2x1dGlvbnMubmV0PiAyLjAuMC1hbHQyCi0gVXBkYXRlZCB0byAyLjQu MjFyYzIgLSB2c3ByaW50ZiBwYXRjaCByZW1vdmVkCgoqIFdlZCBBcHIgMzAgMjAwMyBFZCBWLiBC YXJ0b3NoIDxlZEBzYW0tc29sdXRpb25zLm5ldD4gMi4wLjAtYWx0MQotIFVwZGF0ZWQgZm9yIEVW TVMgMi4wCgoqIE1vbiBBcHIgMjggMjAwMyBFZCBWLiBCYXJ0b3NoIDxlZEBzYW0tc29sdXRpb25z Lm5ldD4gMS4yLjEtYWx0NAotIGF0YXJhaWQtcmVsYXRlZCBwYXRjaGVzIHJlbW92ZWQKCiogRnJp IEFwciAxOCAyMDAzIEVkIFYuIEJhcnRvc2ggPGVkQHNhbS1zb2x1dGlvbnMubmV0PiAxLjIuMS1h bHQzCi0gbmFtZSBvZiB0aGUgcGFja2FnZSBjaGFuZ2VkLCBzcGVjIHN5bnRheCBpbXByb3ZlbWVu dHMKCiogVHVlIEFwciAgOCAyMDAzIEVkIFYuIEJhcnRvc2ggPGVkQHNhbS1zb2x1dGlvbnMubmV0 PiAxLjIuMS1hbHQyCi0gRG93bmdyYWRlZCB0byAxLjIuMQoKKiBNb24gTWFyIDMxIDIwMDMgUGV0 ZXIgTm92b2R2b3Jza3kgPG5pZGRAYWx0bGludXguY29tPiAxLjkuMi1hbHQxCi0gSW5pdGlhbCBy ZWxlYXNlCgo= --Multipart_Wed__25_Jun_2003_17:02:47_+0400_084ca3f0-- --=.H,mH9H?_L608w2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE++Z16W82GfkQfsqIRApslAJ9Bm66gks2VMejT8dCeE2Ti/PEptgCgiNBz rlPOlXFiC65pS9AZYiq3t3c= =MpxO -----END PGP SIGNATURE----- --=.H,mH9H?_L608w2-- >From gorev@mail333.com Wed Jun 25 17:11:34 2003 Return-Path: <gorev@mail333.com> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id D126D49B53 for <devel-kernel@lrn.ru>; Wed, 25 Jun 2003 17:11:32 +0400 (MSD) Received: from main.avilink.net (main.avilink.net [217.21.50.1]) by master.altlinux.ru (Postfix) with ESMTP id A4109E31CF for <devel-kernel@altlinux.ru>; Wed, 25 Jun 2003 17:11:23 +0400 (MSD) Received: from mail333.com (horror.avilink [10.0.15.19]) by main.avilink.net (8.12.8/8.12.8) with ESMTP id h5PDBN6V028004 for <devel-kernel@altlinux.ru>; Wed, 25 Jun 2003 16:11:23 +0300 Message-ID: <3EF99F76.4040909@mail333.com> Date: Wed, 25 Jun 2003 16:11:18 +0300 From: Andy Gorev <gorev@mail333.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030331 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: devel-kernel@altlinux.ru Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Subject: [d-kernel] =?koi8-r?b?8cTSxc7ZyiDOxcvPzdDMxcvUINcgQ8naycbF?= X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Wed, 25 Jun 2003 13:11:35 -0000 Есть ядра без пары. Похоже на ошибку incominger-а kernel-image-std-up-2.4.21rel-alt1.i586.rpm kernel-image-std-smp-2.4.21rc1-alt3.i586.rpm -- С Уважением, Андрей Горев
Алексей Любимов wrote:
> Как бы сделать depmod не того ядра, которое в текущий момент работает?
/sbin/depmod -ae -F System.map your-kernel
man depmod?
--
С Уважением,
Андрей Горев
Andy Gorev пишет: > Алексей Любимов wrote: > >> Как бы сделать depmod не того ядра, которое в текущий момент работает? > > > /sbin/depmod -ae -F System.map your-kernel спасибо. > > man depmod? > Думаешь, не читал? :) Просто опцию e проглядел. Однако пролема осталась: [root@avl root]# mkinitrd /boot/initrd-2.4.21rc1-std-smp-alt3.img 2.4.21rc1-std-smp-alt3 No module sym53c8xx found for kernel 2.4.21rc1-std-smp-alt3 open /dev/fb0: No such device [root@avl root]# find /lib/modules/2.4.21rc1-std-smp-alt3/ -name "sym*" /lib/modules/2.4.21rc1-std-smp-alt3/kernel/drivers/scsi/sym53c416.o /lib/modules/2.4.21rc1-std-smp-alt3/kernel/drivers/scsi/sym53c8xx.o /lib/modules/2.4.21rc1-std-smp-alt3/kernel/drivers/scsi/sym53c8xx_2 /lib/modules/2.4.21rc1-std-smp-alt3/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.o Вот не понимаю, что ему еще может быть нужно?
[-- Attachment #1: Type: text/plain, Size: 248 bytes --] Собственно говоря, вот: $ rpm -ba kernel-std-up.spec ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security kernel-fix-build Может быть стоит как-то зависеть на макросы для сборки ? Если это конечно возможно вообще Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
On Fri, Jul 04, 2003 at 12:36:29AM +0400, Anton Farygin wrote: > Собственно говоря, вот: > $ rpm -ba kernel-std-up.spec > ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security > kernel-fix-build Buildrequires: kernel-build-tools > Может быть стоит как-то зависеть на макросы для сборки ? Если это > конечно возможно вообще Возможно методом починки твоей сборочной среды. Она не должна парсить спек до того, как в ней удовлетворены все BuildRequires пакета. -- / Alexander Bokovoy --- Remember, there's a big difference between kneeling down and bending over. - Frank Zappa >From rider@altlinux.com Fri Jul 4 01:20:50 2003 Return-Path: <rider@altlinux.com> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 8395449AD6 for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 01:20:50 +0400 (MSD) Received: from riderbook.office.altlinux.ru (caltrop.alt.iph.ras.ru [194.67.87.71]) by master.altlinux.ru (Postfix) with ESMTP id 6F73EE31CF for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 01:20:50 +0400 (MSD) Received: from altlinux.com (localhost.localdomain [127.0.0.1]) by riderbook.office.altlinux.ru (Postfix) with ESMTP id 3097522F2E for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 01:09:32 +0400 (MSD) Message-ID: <3F049B87.6060801@altlinux.com> Date: Fri, 04 Jul 2003 01:09:27 +0400 From: Anton Farygin <rider@altlinux.com> Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030627 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] =?KOI8-R?Q?=DA=C1=D7=C9=D3=C9=CD=CF=D3=D4=D8_=CE?= =?KOI8-R?Q?=C1_=CD=C1=CB=D2=CF=D3=D9=3F?= References: <3F0493CD.4030800@altlinux.com> <20030703211236.GE2354@sam-solutions.net> In-Reply-To: <20030703211236.GE2354@sam-solutions.net> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8017496747B6728AA9F0B2EB" Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Thu, 03 Jul 2003 21:20:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8017496747B6728AA9F0B2EB Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Alexander Bokovoy пишет: > On Fri, Jul 04, 2003 at 12:36:29AM +0400, Anton Farygin wrote: > >>Собственно говоря, вот: >>$ rpm -ba kernel-std-up.spec >>ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security >>kernel-fix-build > > Buildrequires: kernel-build-tools $ cat kernel-std-up.spec |grep build-tools BuildRequires: kernel-build-tools $ rpm -q --specfile kernel-std-up.spec kernel-image-std-up-2.4.21rel-alt1 > > >>Может быть стоит как-то зависеть на макросы для сборки ? Если это >>конечно возможно вообще > > Возможно методом починки твоей сборочной среды. Она не должна парсить спек > до того, как в ней удовлетворены все BuildRequires пакета. > Моя сборочная среда == текущий Sisyphus. Даже не в BTE. Rgds, Rider --------------enig8017496747B6728AA9F0B2EB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/BJuLqohfd2vlwKsRApGWAJ9mOyJOGA295E0pI9+YTTJ5s/tvyACgslHd 8eP8SbD9C6oNpLOaxl9Qrbs= =juWY -----END PGP SIGNATURE----- --------------enig8017496747B6728AA9F0B2EB--
On Fri, Jul 04, 2003 at 01:09:27AM +0400, Anton Farygin wrote: > Alexander Bokovoy пишет: > >On Fri, Jul 04, 2003 at 12:36:29AM +0400, Anton Farygin wrote: > > > >>Собственно говоря, вот: > >>$ rpm -ba kernel-std-up.spec > >>ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security > >>kernel-fix-build > > > >Buildrequires: kernel-build-tools > > $ cat kernel-std-up.spec |grep build-tools > BuildRequires: kernel-build-tools > > $ rpm -q --specfile kernel-std-up.spec > kernel-image-std-up-2.4.21rel-alt1 А сам пакет установлен? kernel-build-tools? > >>Может быть стоит как-то зависеть на макросы для сборки ? Если это > >>конечно возможно вообще > > > >Возможно методом починки твоей сборочной среды. Она не должна парсить спек > >до того, как в ней удовлетворены все BuildRequires пакета. > Моя сборочная среда == текущий Sisyphus. Даже не в BTE. Это не важно. Вначале удовлетвори все зависимости -- поставь пакет kernel-build-tools. -- / Alexander Bokovoy --- If it has syntax, it isn't user friendly. >From rider@altlinux.com Fri Jul 4 01:35:47 2003 Return-Path: <rider@altlinux.com> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 982994995A for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 01:35:47 +0400 (MSD) Received: from riderbook.office.altlinux.ru (caltrop.alt.iph.ras.ru [194.67.87.71]) by master.altlinux.ru (Postfix) with ESMTP id 66C9CE31CF for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 01:35:47 +0400 (MSD) Received: from altlinux.com (localhost.localdomain [127.0.0.1]) by riderbook.office.altlinux.ru (Postfix) with ESMTP id 106DF22F2E for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 01:24:29 +0400 (MSD) Message-ID: <3F049F08.2080207@altlinux.com> Date: Fri, 04 Jul 2003 01:24:24 +0400 From: Anton Farygin <rider@altlinux.com> Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030627 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] =?KOI8-R?Q?=DA=C1=D7=C9=D3=C9=CD=CF=D3=D4=D8_=CE?= =?KOI8-R?Q?=C1_=CD=C1=CB=D2=CF=D3=D9=3F?= References: <3F0493CD.4030800@altlinux.com> <20030703211236.GE2354@sam-solutions.net> <3F049B87.6060801@altlinux.com> <20030703212326.GG2354@sam-solutions.net> In-Reply-To: <20030703212326.GG2354@sam-solutions.net> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig99CBA9B9976DFA758166F599" Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Thu, 03 Jul 2003 21:35:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig99CBA9B9976DFA758166F599 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Alexander Bokovoy пишет: > On Fri, Jul 04, 2003 at 01:09:27AM +0400, Anton Farygin wrote: > >>Alexander Bokovoy пишет: >> >>>On Fri, Jul 04, 2003 at 12:36:29AM +0400, Anton Farygin wrote: >>> >>> >>>>Собственно говоря, вот: >>>>$ rpm -ba kernel-std-up.spec >>>>ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security >>>>kernel-fix-build >>> >>>Buildrequires: kernel-build-tools >> >>$ cat kernel-std-up.spec |grep build-tools >>BuildRequires: kernel-build-tools >> >>$ rpm -q --specfile kernel-std-up.spec >>kernel-image-std-up-2.4.21rel-alt1 > > А сам пакет установлен? kernel-build-tools? Сейчас уже установлен. Раньше - не был установлен, но при этом rpmbuild его не просил для сборки ядра. > > >>>>Может быть стоит как-то зависеть на макросы для сборки ? Если это >>>>конечно возможно вообще >>> >>>Возможно методом починки твоей сборочной среды. Она не должна парсить спек >>>до того, как в ней удовлетворены все BuildRequires пакета. >> >>Моя сборочная среда == текущий Sisyphus. Даже не в BTE. > > Это не важно. Вначале удовлетвори все зависимости -- поставь пакет > kernel-build-tools. Это я знаю, спасибо ;-) Rgds, Rider --------------enig99CBA9B9976DFA758166F599 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/BJ8Mqohfd2vlwKsRAj6mAKCJOGlF99VnG/SPajPa0xJxGnyGkQCgqUr7 5mUAXHbm2Mid9b53Pmm3VQ8= =paCw -----END PGP SIGNATURE----- --------------enig99CBA9B9976DFA758166F599--
On Fri, Jul 04, 2003 at 01:24:24AM +0400, Anton Farygin wrote: > >>>>Собственно говоря, вот: > >>>>$ rpm -ba kernel-std-up.spec > >>>>ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security > >>>>kernel-fix-build > >>> > >>>Buildrequires: kernel-build-tools > >> > >>$ cat kernel-std-up.spec |grep build-tools > >>BuildRequires: kernel-build-tools > >> > >>$ rpm -q --specfile kernel-std-up.spec > >>kernel-image-std-up-2.4.21rel-alt1 > > > >А сам пакет установлен? kernel-build-tools? > > Сейчас уже установлен. Раньше - не был установлен, но при этом rpmbuild > его не просил для сборки ядра. Это проблема курицы и яйца -- для того, чтобы начать сборку, rpmbuild должен разобрать первую часть spec-файла, для того, что отрапортовать о недостающих зависимостях, необходимо, чтобы к моменту окончания обработки этой первой части все было ОК. Вообщем, правильное решение будет apt-get build-dep kernel-image-std-up # apt-get build-dep kernel-image-std-up Reading Package Lists... Done Collecting File Provides... Done Building Dependency Tree... Done The following NEW packages will be installed: cpp2.96 dev86 gcc2.96 kernel-build-tools kernel-feat-addon kernel-feat-bttv kernel-feat-core-O1sched kernel-feat-crypto kernel-feat-drivers-video-splash kernel-feat-fs-xfs kernel-feat-iscsi kernel-feat-kconfig kernel-feat-net-ipsec kernel-feat-net-ppp-mppe kernel-fix-build kernel-fix-core kernel-fix-security kernel-source-2.4.21 0 packages upgraded, 18 newly installed, 0 removed and 0 not upgraded. Need to get 0B/33.1MB of archives. After unpacking 43.5MB of additional disk space will be used. Do you want to continue? [Y/n] -- / Alexander Bokovoy --- Normal times may possibly be over forever. >From ab@samba.org Fri Jul 4 01:46:03 2003 Return-Path: <ab@samba.org> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 2E8654995A for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 01:46:03 +0400 (MSD) Received: from dp.samba.org (ns.telecom.by [213.184.225.1]) by master.altlinux.ru (Postfix) with ESMTP id 949DDE31D4 for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 01:46:02 +0400 (MSD) Received: by dp.samba.org (Postfix, from userid 500) id 9705960009D; Fri, 4 Jul 2003 00:46:30 +0300 (EEST) Date: Fri, 4 Jul 2003 00:46:30 +0300 From: Alexander Bokovoy <a.bokovoy@sam-solutions.net> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] =?koi8-r?B?8MzBzsnS1cXU09Eg?= =?koi8-r?B?zMkg0MXSxcjPxMnU2CDOwQ==?= devfs? Message-ID: <20030703214630.GI2354@sam-solutions.net> References: <3F04A27B.5090102@l14.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3F04A27B.5090102@l14.ru> X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Thu, 03 Jul 2003 21:46:03 -0000 On Fri, Jul 04, 2003 at 01:39:07AM +0400, Алексей Любимов wrote: > Планируется ли переходить на devfs? > Что думают в стане разработчиков? Пока Al Viro дал отрицательный отклик месяца три назад, обнаружив вполне реальные race conditions в коде devfs, особенно касающиеся завершения работы модулей. Я бы поостерегся, но Виктор Форсюк, наверное, наиболее опытный пользователь devfs среди участников Team, послушаем, что скажет он? -- / Alexander Bokovoy --- You dialed 5483. >From ldv@altlinux.org Fri Jul 4 03:01:24 2003 Return-Path: <ldv@altlinux.org> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 9319C499A0 for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 03:01:24 +0400 (MSD) Received: from basalt.office.altlinux.org (localhost.localdomain [127.0.0.1]) by master.altlinux.ru (Postfix) with ESMTP id 74F51E31CF for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 03:01:24 +0400 (MSD) Received: by basalt.office.altlinux.org (Postfix, from userid 501) id 5932F10C2; Fri, 4 Jul 2003 03:01:24 +0400 (MSD) Date: Fri, 4 Jul 2003 03:01:24 +0400 From: "Dmitry V. Levin" <ldv@altlinux.org> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] =?koi8-r?B?2sHXydPJzc/T?= =?koi8-r?B?1NggzsEgzcHL0s/T2T8=?= Message-ID: <20030703230124.GB17480@basalt.office.altlinux.org> Mail-Followup-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> References: <3F0493CD.4030800@altlinux.com> <20030703211236.GE2354@sam-solutions.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: <20030703211236.GE2354@sam-solutions.net> X-fingerprint: 9658 398D 181B 1200 8FC5 26B8 F6F8 846B C1E2 3429 X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Thu, 03 Jul 2003 23:01:24 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Jul 04, 2003 at 12:12:36AM +0300, Alexander Bokovoy wrote: > On Fri, Jul 04, 2003 at 12:36:29AM +0400, Anton Farygin wrote: > > Собственно говоря, вот: > > $ rpm -ba kernel-std-up.spec > > ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security > > kernel-fix-build > Buildrequires: kernel-build-tools > > > Может быть стоит как-то зависеть на макросы для сборки ? Если это > > конечно возможно вообще > Возможно методом починки твоей сборочной среды. Она не должна парсить спек > до того, как в ней удовлетворены все BuildRequires пакета. В данном случае можно предусмотреть workaround в spec-файле: перенести использование некоторых нестандартных макросов ниже по тексту, например, в %prep, чтобы rpmbuild мог честно выругаться на неудовлетворенные зависимости. Иногда, правда, этот трюк не удается; например, если сам BuildPreReq использует макросы. Но это уже совсем другая история. -- ldv --dTy3Mrz/UPE2dbVg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/BLXE9viEa8HiNCkRAlT/AJ9GCrj5tPqBnGCdxcFmxXb/6yZMgwCeNuhR g5eFGixQCN7iqkfe2GAqk2I= =LbJq -----END PGP SIGNATURE----- --dTy3Mrz/UPE2dbVg-- >From ab@samba.org Fri Jul 4 10:40:58 2003 Return-Path: <ab@samba.org> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id ACAF349AE6 for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 10:40:58 +0400 (MSD) Received: from dp.samba.org (ns.telecom.by [213.184.225.1]) by master.altlinux.ru (Postfix) with ESMTP id B0956E31D0 for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 10:40:57 +0400 (MSD) Received: by dp.samba.org (Postfix, from userid 500) id EFC7260009D; Fri, 4 Jul 2003 09:41:23 +0300 (EEST) Date: Fri, 4 Jul 2003 09:41:23 +0300 From: Alexander Bokovoy <a.bokovoy@sam-solutions.net> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] =?koi8-r?B?2sHXydPJzc/T?= =?koi8-r?B?1NggzsEgzcHL0s/T2T8=?= Message-ID: <20030704064123.GA3594@sam-solutions.net> References: <3F0493CD.4030800@altlinux.com> <20030703211236.GE2354@sam-solutions.net> <20030703230124.GB17480@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20030703230124.GB17480@basalt.office.altlinux.org> X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Fri, 04 Jul 2003 06:40:59 -0000 On Fri, Jul 04, 2003 at 03:01:24AM +0400, Dmitry V. Levin wrote: > On Fri, Jul 04, 2003 at 12:12:36AM +0300, Alexander Bokovoy wrote: > > On Fri, Jul 04, 2003 at 12:36:29AM +0400, Anton Farygin wrote: > > > Собственно говоря, вот: > > > $ rpm -ba kernel-std-up.spec > > > ошибка: строка 18: Неизвестный тэг: %add_patch_list kernel-fix-security > > > kernel-fix-build > > Buildrequires: kernel-build-tools > > > > > Может быть стоит как-то зависеть на макросы для сборки ? Если это > > > конечно возможно вообще > > Возможно методом починки твоей сборочной среды. Она не должна парсить спек > > до того, как в ней удовлетворены все BuildRequires пакета. > > В данном случае можно предусмотреть workaround в spec-файле: > перенести использование некоторых нестандартных макросов ниже по тексту, > например, в %prep, чтобы rpmbuild мог честно выругаться на > неудовлетворенные зависимости. В данном случае это не удастся, так как %add_patch_list помимо запоминания подставленного значения также генерирует строку BuildRequires: с этим значением. > Иногда, правда, этот трюк не удается; например, если сам BuildPreReq > использует макросы. Но это уже совсем другая история. Здесь похожая ситуация: %add_patch_list должен использоваться до %prep, чтобы сгенерировать buildrequires. -- / Alexander Bokovoy --- QOTD: "It's been real and it's been fun, but it hasn't been real fun." >From ed@altlinux.ru Fri Jul 4 11:30:06 2003 Return-Path: <ed@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 35B0049BBA for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 11:30:06 +0400 (MSD) Received: from mail.belcaf.minsk.by (mail.sam-solutions.net [217.21.35.41]) by master.altlinux.ru (Postfix) with ESMTP id 57109E31CF for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 11:30:04 +0400 (MSD) Received: from pc213.sam-solutions.net ([192.168.111.243]) by mail.belcaf.minsk.by (MTA 4.15) with ESMTP id HHHOTH00.PP4 for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 10:29:41 +0300 Received: from pc213.sam-solutions.net (localhost.localdomain [127.0.0.1]) h646Su62002565 for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 10:28:56 +0400 Received: (from ed@localhost) by pc213.sam-solutions.net (8.12.9/8.12.6/Submit) id h646StA6002564; Fri, 4 Jul 2003 10:28:55 +0400 X-Comment-To: Sergey Vlasov To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] Re: new/updated kernel packages In-Reply-To: <20030702201730.1ea25eef.vsu@altlinux.ru> (Sergey Vlasov's message of "Wed, 2 Jul 2003 20:17:30 +0400") References: <m3of0es3cp.fsf@altlinux.ru> <20030702201730.1ea25eef.vsu@altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Fri, 04 Jul 2003 10:28:55 +0400 Message-ID: <m3n0fu4xg8.fsf@altlinux.ru> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Fri, 04 Jul 2003 07:30:06 -0000 >>>>> "SV" == Sergey Vlasov writes: SV> ed@altlinux.ru (Ed V. Bartosh) wrote: >> Заливаю в incoming/Sysiphus/BTE: SV> Вот сейчас только добрался всё это разобрать - не работает :-( SV> Во всех пакетах kernel-{feat,fix}-* мусор в changelog (там % SV> нужно дублировать, иначе макросы раскрываются). SV> kernel-feat-acpi-2003.06.19-alt1.src.rpm не пересобирается (надо SV> s/install_sources/install_patches/). сейчас исправлю/залью. -- Best regards, Ed V. Bartosh >From ed@altlinux.ru Fri Jul 4 12:05:14 2003 Return-Path: <ed@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 0CAA749AB8 for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 12:05:14 +0400 (MSD) Received: from mail.belcaf.minsk.by (mail.sam-solutions.net [217.21.35.41]) by master.altlinux.ru (Postfix) with ESMTP id 3B0CFE31CF for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 12:05:12 +0400 (MSD) Received: from pc213.sam-solutions.net ([192.168.111.243]) by mail.belcaf.minsk.by (MTA 4.15) with ESMTP id HHHQGM00.HOY for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 11:05:10 +0300 Received: from pc213.sam-solutions.net (localhost.localdomain [127.0.0.1]) h6474P62002853 for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 11:04:25 +0400 Received: (from ed@localhost) by pc213.sam-solutions.net (8.12.9/8.12.6/Submit) id h6474Psd002852; Fri, 4 Jul 2003 11:04:25 +0400 X-Comment-To: Peter Novodvorsky To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] Re: new/updated kernel packages In-Reply-To: <87u1a4evex.fsf@velvet.po.cs.msu.su> (Peter Novodvorsky's message of "Wed, 02 Jul 2003 20:38:14 +0400") References: <m3of0es3cp.fsf@altlinux.ru> <20030702202329.5ed799db.vsu@altlinux.ru> <87u1a4evex.fsf@velvet.po.cs.msu.su> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Fri, 04 Jul 2003 11:04:25 +0400 Message-ID: <m3isqi4vt2.fsf@altlinux.ru> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Fri, 04 Jul 2003 08:05:14 -0000 >>>>> "PN" == Peter Novodvorsky writes: >>> 8dc94c940c4ae8b205151aec0270886b >>> kernel-feat-addon-2003.05.29-alt2.noarch.rpm >>> 069f9ff563c170ae1a300024cc83c7da >>> kernel-feat-addon-2003.05.29-alt2.src.rpm >> >> Тут какая-то рассинхронизация получилась - в Сизифе уже >> 2003.06.21-alt1. Надо что-то по этому поводу делать... PN> Это я поймал и исправил. А чего install_patches выкинул ? Не понравилось :) ? -- Best regards, Ed V. Bartosh >From rider@altlinux.com Fri Jul 4 12:17:34 2003 Return-Path: <rider@altlinux.com> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 44EAC49BA0 for <devel-kernel@lrn.ru>; Fri, 4 Jul 2003 12:17:26 +0400 (MSD) Received: from riderbook.office.altlinux.ru (caltrop.alt.iph.ras.ru [194.67.87.71]) by master.altlinux.ru (Postfix) with ESMTP id 0DE99E31CF for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 12:17:26 +0400 (MSD) Received: from altlinux.com (localhost.localdomain [127.0.0.1]) by riderbook.office.altlinux.ru (Postfix) with ESMTP id B7EF222F60 for <devel-kernel@altlinux.ru>; Fri, 4 Jul 2003 12:06:04 +0400 (MSD) Message-ID: <3F053568.6070703@altlinux.com> Date: Fri, 04 Jul 2003 12:06:00 +0400 From: Anton Farygin <rider@altlinux.com> Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030627 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B76B9DE9E09ECC01F5D80F8" Subject: [d-kernel] =?koi8-r?b?8MHU3iDEzNEgc2QuYw==?= X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Fri, 04 Jul 2003 08:17:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B76B9DE9E09ECC01F5D80F8 Content-Type: multipart/mixed; boundary="------------080202030901060201000203" This is a multi-part message in MIME format. --------------080202030901060201000203 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Привет всем. Собственно после долгих раздумьях о нормальных способах получения информации о том, какому SCSI диску какой /dev/sd* соответствует - Маузом был написан небольшой патчик на sd, добавляющий /proc/scsi/scsi_sd, выводящий информацию такого вида: $ cat /proc/scsi/scsi_sd sda: scsi 1(0,0,0) sdb: scsi 2(0,0,0) Что будет очень удобно для распознавания вставляемых USB устройств (FLASH, Floppy и т.д.) Просьба его включить в std ядра в самой ближайшей сборке. Это критично для выпуска J следующих версий (там будет автоопределение + автоподключение FLASH дисков) Rgds, Rider --------------080202030901060201000203 Content-Type: text/plain; name="linux-2.4.21-altlinux-scsi-addproc-sd.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="linux-2.4.21-altlinux-scsi-addproc-sd.patch" diff -ur kernel-source-2.4.21.orig/drivers/scsi/sd.c kernel-source-2.4.21/drivers/scsi/sd.c --- kernel-source-2.4.21.orig/drivers/scsi/sd.c 2003-06-13 18:51:36 +0400 +++ kernel-source-2.4.21/drivers/scsi/sd.c 2003-07-04 11:46:06 +0400 @@ -1421,8 +1421,45 @@ return; } +#ifdef CONFIG_PROC_FS +static int scsi_proc_hostno(char *page, char **start, off_t off, int count, int *eof, void *data) +{ + Scsi_Disk *dpnt; + Scsi_Device *sdp; + int i, size, len = 0; + char nbuff[6]; + + for (dpnt = rscsi_disks, i=0; i < sd_template.nr_dev; i++, dpnt++) { + if (!dpnt->device) + continue; + sdp = dpnt->device; + sd_devname(i, nbuff); + size = sprintf(page + len, "%s: scsi%02d(%d,%d,%d)\n", nbuff, sdp->host->host_no, sdp->channel, sdp->id, sdp->lun); + len += size; + } + if (len <= off+count) + *eof = 1; + *start = page + off; + len -= off; + if (len > count) + len = count; + if (len < 0) + len = 0; + return (len); +} +#endif + static int __init init_sd(void) { +#ifdef CONFIG_PROC_FS + struct proc_dir_entry *hostno; + + hostno = create_proc_read_entry ("scsi/scsi_sd", 0, NULL, scsi_proc_hostno, NULL); + if (!hostno) { + printk (KERN_ERR "cannot init /proc/scsi/scsi_sd\n"); + return -ENOMEM; + } +#endif sd_template.module = THIS_MODULE; return scsi_register_module(MODULE_SCSI_DEV, &sd_template); } --------------080202030901060201000203-- --------------enig1B76B9DE9E09ECC01F5D80F8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/BTVsqohfd2vlwKsRAodxAJ9Y8brTlVdf8fX+gO16+1cuoDryXQCgs0yO JUbRj03cCc36H9WM6FzjVRY= =UuOE -----END PGP SIGNATURE----- --------------enig1B76B9DE9E09ECC01F5D80F8--
Тут еще один мелкий глючок в спеке (std-up, да и в остальных тоже): echo " RPM { Allow-Duplicated {"^kernel-image-%{flavour}$";}; }; " > $RPM_BUILD_ROOT/etc/apt/apt.conf.d/kernel-image-%{flavour}.conf делает не совсем то, что, как мне кажется, предполалось авторами. По-моему, уместно написать echo ' и далее по тексту. Иначе двойные кавычки не попадают в apt'овый конфиг. Ну, и неплохо было бы приписать туда же разрешение на дупликацию хидеров. И почетче разграничить разницу между %version и %kversion. В большей части спека должен использоваться именно %kversion. Это позволяет собрать ядра вида 2.4.21-что-то-там-alt1 (что выглядит "естественно" для глаза), и класть и в пакеты 2.4.21rel-что-то-там-alt1 (что выглядит естественно для RPM'а при апгрейде с 2.4.21rcN). 2Mike Shigorin: Михаил, все же механизм Epoch - по моему, слишком тяжелая дубина для такого случая. Перепрыгивать с ядра на ядро (н-р, с целью поиграться с 2.5 и откатиться обратно) становится крайне неприятно, т.к. в этом случае трудно обеспечить необходимый порядок для этих самых Epoch, если в процессе игр участвует более одной машины.
On Tue, Jul 08, 2003 at 07:33:42PM +0700, Alexey Morozov wrote: > Неплохо было бы /заполучить/ механизм автоматического > добавления в modules.conf модулей, которые доставляются > отдельными от ядра пакетами. Если я правильно понял tren -- в демьяне оно так и есть. > Да, кстати, я собрал (ну, за исключением /правильного/ > автоматического прописывания в modules.conf) ауриаловские > модули в новой схеме. Если есть желающие, отошлю оба > (kernel-source-aureal и kernel-modules-aureal) спека. Если никто не возьмет -- пойду фолбэком... -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ >From nidd@velvet.po.cs.msu.su Tue Jul 8 17:06:19 2003 Return-Path: <nidd@velvet.po.cs.msu.su> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id D367B494FF for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 17:06:19 +0400 (MSD) Received: from velvet.po.cs.msu.su (velvet.po.cs.msu.su [158.250.16.34]) by master.altlinux.ru (Postfix) with ESMTP id C6551E31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:06:19 +0400 (MSD) Received: from nidd by velvet.po.cs.msu.su with local (Exim 3.35 #1 (Debian)) id 19ZsAC-0007TA-00 for <devel-kernel@altlinux.ru>; Tue, 08 Jul 2003 17:05:44 +0400 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] New kernel packages with flavour llc to Incoming/Sisyphus References: <200307071517.51640.darkstar@altlinux.ru> <20030708151859.06e904b9.Egor.Orlov@avalon.ru> From: Peter Novodvorsky <nidd@myxomop.com> Organization: Intoxicated by Myxomop Date: Tue, 08 Jul 2003 17:05:44 +0400 In-Reply-To: <20030708151859.06e904b9.Egor.Orlov@avalon.ru> (Egor S. Orlov's message of "Tue, 8 Jul 2003 15:18:59 +0400") Message-ID: <87y8z9qic7.fsf@velvet.po.cs.msu.su> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: Peter Novodvorsky <nidd@velvet.po.cs.msu.su> X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 13:06:20 -0000 "Egor S. Orlov" <Egor.Orlov@avalon.ru> writes: > все собралось и работает, но depmod ругается: > # depmod -a > depmod: *** Unresolved symbols in > /lib/modules/2.4.21-llc-up-alt1/kernel/drivers/char/drm/gamma.o > depmod: *** Unresolved symbols in > /lib/modules/2.4.21-llc-up-alt1/kernel/drivers/char/drm/gamma_drv.o я поправил drm-std-up.spec, чтобы он не не собирал gamma.o. этот драйвер officialy глючит. Nidd. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite! >From Egor.Orlov@avalon.ru Tue Jul 8 17:26:48 2003 Return-Path: <Egor.Orlov@avalon.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id A331E494FF for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 17:26:48 +0400 (MSD) Received: from smtp.avalon.ru (ns.avalon.ru [195.209.229.227]) by master.altlinux.ru (Postfix) with ESMTP id 329B4E31D0 for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:26:48 +0400 (MSD) Received: from oes-buk.avalon.ru ([192.168.1.223]) by smtp.avalon.ru with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 17:27:40 +0400 Date: Tue, 8 Jul 2003 17:26:59 +0400 From: "Egor S. Orlov" <Egor.Orlov@avalon.ru> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] New kernel packages with flavour llc to Incoming/Sisyphus Message-Id: <20030708172659.57055a3f.Egor.Orlov@avalon.ru> In-Reply-To: <87y8z9qic7.fsf@velvet.po.cs.msu.su> References: <200307071517.51640.darkstar@altlinux.ru> <20030708151859.06e904b9.Egor.Orlov@avalon.ru> <87y8z9qic7.fsf@velvet.po.cs.msu.su> Organization: FST SPbSPU X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.(XBBw2_h,Ko.Ta" X-OriginalArrivalTime: 08 Jul 2003 13:27:40.0795 (UTC) FILETIME=[B4B6BCB0:01C34554] X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 13:26:49 -0000 --=.(XBBw2_h,Ko.Ta Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 T24gVHVlLCAwOCBKdWwgMjAwMyAxNzowNTo0NCArMDQwMA0KUGV0ZXIgTm92b2R2b3Jza3kgPG5p ZGRAbXl4b21vcC5jb20+IHdyb3RlOg0KDQo+ICJFZ29yIFMuIE9ybG92IiA8RWdvci5PcmxvdkBh dmFsb24ucnU+IHdyaXRlczoNCj4gDQo+ID4g19PFINPPwtLBzM/T2CDJINLBws/UwcXULCDOzyBk ZXBtb2Qg0tXHwcXU09E6DQo+ID4gIyBkZXBtb2QgLWENCj4gPiBkZXBtb2Q6ICoqKiBVbnJlc29s dmVkIHN5bWJvbHMgaW4NCj4gPiAvbGliL21vZHVsZXMvMi40LjIxLWxsYy11cC1hbHQxL2tlcm5l bC9kcml2ZXJzL2NoYXIvZHJtL2dhbW1hLm8gDQo+ID4gZGVwbW9kOiAqKiogVW5yZXNvbHZlZCBz eW1ib2xzIGluDQo+ID4gL2xpYi9tb2R1bGVzLzIuNC4yMS1sbGMtdXAtYWx0MS9rZXJuZWwvZHJp dmVycy9jaGFyL2RybS9nYW1tYV9kcnYubw0KPiANCj4g0SDQz9DSwdfJzCBkcm0tc3RkLXVwLnNw ZWMsIN7Uz8LZIM/OIM7FIM7FINPPwsnSwcwgZ2FtbWEuby4g3NTP1A0KPiDE0sHK18XSIG9mZmlj aWFseSDHzMDeydQuDQo+IA0KPiBOaWRkLg0KDQrUz9QsIMvP1M/S2cog1w0Ka2VybmVsLW1vZHVs ZXMtZHJtLXN0ZC11cC00LjMuMC1hbHQ3LnNyYy5ycG0/DQoNCi0tIA0KV0JSLCBFZ29yIFMuIE9y bG92DQpGU1QgU1BiU1BVDQo= --=.(XBBw2_h,Ko.Ta Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Csak2ryY9MmM89IRAiGsAJ4oZa/JPxOVxbiekEvuPh+Oj+TGggCgqHwp bW4vvTfcO8F6YZDHO/WEKRA= =tD2t -----END PGP SIGNATURE----- --=.(XBBw2_h,Ko.Ta-- >From tren@altlinux.ru Tue Jul 8 18:28:12 2003 Return-Path: <tren@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 5F2CC4953B for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 18:28:12 +0400 (MSD) Received: from mail.belcaf.minsk.by (mail.sam-solutions.net [217.21.35.41]) by master.altlinux.ru (Postfix) with ESMTP id 4EF4DE31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 18:28:08 +0400 (MSD) Received: from pc347.belcaf.minsk.by ([192.168.111.217]) by mail.belcaf.minsk.by (MTA 4.15) with ESMTP id HHPMUU00.BAO for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:28:06 +0300 Received: from pc347.belcaf.minsk.by (localhost [127.0.0.1]) h68ES714024368 for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:28:07 +0300 Received: (from tren@localhost) by pc347.belcaf.minsk.by (8.12.9/8.12.9/Debian-3) id h68ES6Hs024366; Tue, 8 Jul 2003 17:28:06 +0300 X-Authentication-Warning: pc347.belcaf.minsk.by: tren set sender to tren@altlinux.ru using -f X-Comment-To: Ed V. Bartosh To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] new evms packages References: <m3fzlqs2di.fsf@altlinux.ru> From: Zhenja Kaluta <tren@altlinux.ru> Organization: Alt linux Team Date: Tue, 08 Jul 2003 17:28:06 +0300 In-Reply-To: <m3fzlqs2di.fsf@altlinux.ru> (Ed V. Bartosh's message of "Tue, 01 Jul 2003 19:17:13 +0400") Message-ID: <87n0fphz49.fsf@pc347.belcaf.minsk.by> User-Agent: Gnus v5.10.2/GNU Emacs 21.3 (Debian GNU/Linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: base64 X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 14:28:12 -0000 DQppbmNvbWluZy9TaXN5cGh1cy9CVEUNCg0KNjlhMzFiZDczOGU5NTdjMmQ4Yzk1OGNlZjgzNGI1 MTUgIGV2bXMtMi4xLjAtYWx0My5pNTg2LnJwbQ0KZjFjM2YwOWM5YTM0ZTBjYzA4MmQyNmVmMzBk NjQ0YzcgIGV2bXMtMi4xLjAtYWx0My5zcmMucnBtDQo5MTQ3MzViMWYzNTNmMTI5Mjk0ODBkYzI4 ZTc2YjllZiAgZXZtcy1jbGktMi4xLjAtYWx0My5pNTg2LnJwbQ0KNGIyYzkwYWE4NzlmZDMyZmQ2 Mjc3MTY0ZDAyODQ5MTEgIGV2bXMtZ3VpLTIuMS4wLWFsdDMuaTU4Ni5ycG0NCjc5NmMyZGQwODFm NjBlYzgwNzA2NWJhMzFhMzlhZjU0ICBldm1zLW5jdXJzZXMtMi4xLjAtYWx0My5pNTg2LnJwbQ0K NDY0M2E4NGMyMTQyNTA1OGI5NGI4YTQ4ZThhODYwN2MgIGxpYmV2bXMtMi4xLjAtYWx0My5pNTg2 LnJwbQ0KODdmYmNjY2E3YWMwNmJiYmZhMDA5ZjRkNDcwZGQ3NDIgIGxpYmV2bXMtZGV2ZWwtMi4x LjAtYWx0My5pNTg2LnJwbQ0KDQrT0MHTycLPIHNiLCByYW9ybiwgZWQuDQoNCi0tIA0KWmhlbmph IEthbHV0YSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSUNRIDc0 NTk2MDI3DQpHbnVQRyBGaW5nZXJQcmludDogQjg2QyBCNTQ4IDdDQzQgQjU4RiAwQ0EzICA4NTZF IDdFRTggNTJERSBFNkI3IDg3MjUNCg== >From ed@altlinux.ru Tue Jul 8 18:38:06 2003 Return-Path: <ed@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 856F7494FF for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 18:38:06 +0400 (MSD) Received: from mail.belcaf.minsk.by (mail.sam-solutions.net [217.21.35.41]) by master.altlinux.ru (Postfix) with ESMTP id 93EA5E31D0 for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 18:38:03 +0400 (MSD) Received: from pc213.sam-solutions.net ([192.168.111.243]) by mail.belcaf.minsk.by (MTA 4.15) with ESMTP id HHPNBD00.KA6 for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:38:01 +0300 Received: from pc213.sam-solutions.net (localhost.localdomain [127.0.0.1]) h68DbCv8016586 for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:37:12 +0400 Received: (from ed@localhost) by pc213.sam-solutions.net (8.12.9/8.12.6/Submit) id h68DbC3E016585; Tue, 8 Jul 2003 17:37:12 +0400 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Tue, 08 Jul 2003 17:37:12 +0400 Message-ID: <m3n0fp5ed3.fsf@altlinux.ru> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Subject: [d-kernel] =?iso-8859-1?q?=D0=D2=CF=D3=D8=C2=C1?= X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 14:38:06 -0000 Hello, Просьба анонсить заливаемые в Сизиф новые пакеты/апдейты в этот список, желательно с описанием. Вот, например, что это такое и откуда ? kernel-modules-pctel-sis-std-up-0.9.6-alt1.i586.rpm kernel-source-pctel-0.9.6-0.9.6-alt1.noarch.rpm На списке про это ничего не было, насколько я знаю. -- Best regards, Ed V. Bartosh >From ed@altlinux.ru Tue Jul 8 18:45:19 2003 Return-Path: <ed@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 77EBE494FF for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 18:45:19 +0400 (MSD) Received: from mail.belcaf.minsk.by (mail.sam-solutions.net [217.21.35.41]) by master.altlinux.ru (Postfix) with ESMTP id A5786E31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 18:45:17 +0400 (MSD) Received: from pc213.sam-solutions.net ([192.168.111.243]) by mail.belcaf.minsk.by (MTA 4.15) with ESMTP id HHPNNG00.KA8 for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:45:16 +0300 Received: from pc213.sam-solutions.net (localhost.localdomain [127.0.0.1]) h68DiRv8016658 for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 17:44:27 +0400 Received: (from ed@localhost) by pc213.sam-solutions.net (8.12.9/8.12.6/Submit) id h68DiRGx016657; Tue, 8 Jul 2003 17:44:27 +0400 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Tue, 08 Jul 2003 17:44:26 +0400 Message-ID: <m3k7at5e11.fsf@altlinux.ru> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Subject: [d-kernel] new/updated packages X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 14:45:19 -0000 Hello, Заливаю в Сизиф следующее: 1. vfs-lock fix распилен на две части: 186bf0dfab7c0125a265b6c09e500342 kernel-feat-evms-2.1.0-alt2.noarch.rpm 7f28e6ef0246132898e29274fccb8bcc kernel-feat-evms-2.1.0-alt2.src.rpm bdbd8c03c11cfef399907d3ba8cf6753 kernel-fix-lvm-2003.07.08-alt1.noarch.rpm 7d12a17b777f105729b0ae332effd1a2 kernel-fix-lvm-2003.07.08-alt1.src.rpm 2. фиксы для md (новый пакет) f762e22cd226f59f1dd4a427f3f2f923 kernel-fix-drivers-md-2003.07.08-alt1.noarch.rpm 39561750b8d13fbb25bf4483f60d13ab kernel-fix-drivers-md-2003.07.08-alt1.src.rpm 3. Добавлен kbd_kern-build-alt.patch 2a4c7853dc91745c9bc326a44857be54 kernel-fix-build-2003.04.23-alt6.noarch.rpm 7ab52377e0303fa9fa2b8de9843558c0 kernel-fix-build-2003.04.23-alt6.src.rpm 4. Ядра aw: a0ee72400f71a49e217909001986d54b kernel-headers-aw-smp-2.4.21-alt5.i586.rpm 60f1331fead05c794e54e7ca2bce0db7 kernel-headers-aw-up-2.4.21-alt5.i586.rpm 9306caf9c57883a7dfd3a21794870ae5 kernel-image-aw-smp-2.4.21-alt5.i586.rpm edda9af20dde008b67d44ad2154071c0 kernel-image-aw-smp-2.4.21-alt5.src.rpm a3d00ec3c3bed3ad798b55992a52bdaa kernel-image-aw-up-2.4.21-alt5.i586.rpm 42fe66cf4c89264c3639e2c0d62843ee kernel-image-aw-up-2.4.21-alt5.src.rpm -- Best regards, Ed V. Bartosh >From vsu@altlinux.ru Tue Jul 8 19:22:10 2003 Return-Path: <vsu@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id EAC324815B for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 19:22:09 +0400 (MSD) Received: from mail.mivlgu.ru (mivlgu.ru [81.18.140.87]) by master.altlinux.ru (Postfix) with ESMTP id A28F4E31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 19:22:09 +0400 (MSD) Received: by mail.mivlgu.ru (Postfix, from userid 112) id 29F8E81781; Tue, 8 Jul 2003 19:22:08 +0400 (MSD) Received: from vcserver.mivlgu.local (vcserver.mivlgu.local [192.168.1.251]) by mail.mivlgu.ru (Postfix) with SMTP id 4419E81771; Tue, 8 Jul 2003 19:22:07 +0400 (MSD) Date: Tue, 8 Jul 2003 19:22:06 +0400 From: Sergey Vlasov <vsu@altlinux.ru> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Message-Id: <20030708192206.7b2d3834.vsu@altlinux.ru> In-Reply-To: <m3k7at5e11.fsf@altlinux.ru> References: <m3k7at5e11.fsf@altlinux.ru> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: [d-kernel] Re: new/updated packages X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 15:22:10 -0000 On Tue, 08 Jul 2003 17:44:26 +0400 ed@altlinux.ru (Ed V. Bartosh) wrote: > bdbd8c03c11cfef399907d3ba8cf6753 kernel-fix-lvm-2003.07.08-alt1.noarch.rpm > 7d12a17b777f105729b0ae332effd1a2 kernel-fix-lvm-2003.07.08-alt1.src.rpm Вот тут в %description осталось EVMS. >From nidd@velvet.po.cs.msu.su Tue Jul 8 20:22:10 2003 Return-Path: <nidd@velvet.po.cs.msu.su> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id BDF52481B8 for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 20:22:10 +0400 (MSD) Received: from velvet.po.cs.msu.su (velvet.po.cs.msu.su [158.250.16.34]) by master.altlinux.ru (Postfix) with ESMTP id B19F4E31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 20:22:10 +0400 (MSD) Received: from nidd by velvet.po.cs.msu.su with local (Exim 3.35 #1 (Debian)) id 19ZvDj-0007eb-00 for <devel-kernel@altlinux.ru>; Tue, 08 Jul 2003 20:21:35 +0400 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] =?iso-8859-1?q?=D0=D2=CF=D3=D8=C2=C1?= References: <m3n0fp5ed3.fsf@altlinux.ru> From: Peter Novodvorsky <nidd@myxomop.com> Organization: Intoxicated by Myxomop Date: Tue, 08 Jul 2003 20:21:35 +0400 In-Reply-To: <m3n0fp5ed3.fsf@altlinux.ru> (Ed V. Bartosh's message of "Tue, 08 Jul 2003 17:37:12 +0400") Message-ID: <87r851q99s.fsf@velvet.po.cs.msu.su> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: Peter Novodvorsky <nidd@velvet.po.cs.msu.su> X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 16:22:11 -0000 ed@altlinux.ru (Ed V. Bartosh) writes: > Hello, > > Просьба анонсить заливаемые в Сизиф новые пакеты/апдейты в этот > список, желательно с описанием. > > Вот, например, что это такое и откуда ? > kernel-modules-pctel-sis-std-up-0.9.6-alt1.i586.rpm > kernel-source-pctel-0.9.6-0.9.6-alt1.noarch.rpm > > На списке про это ничего не было, насколько я знаю. Sorry, делал в спешке. Это драйвера для win-модемов в sis матерях, в принципе оттуда же собираются ещё pctel драйвера, но так как они называются точно так же, а конфликтов не хотелось, поэтому я пока собираю только для sis. Это было очень нужно для одного нашего OEM партнёра. nidd. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite! >From vsu@altlinux.ru Tue Jul 8 20:33:04 2003 Return-Path: <vsu@altlinux.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id DDD5849973 for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 20:33:04 +0400 (MSD) Received: from mail.mivlgu.ru (mivlgu.ru [81.18.140.87]) by master.altlinux.ru (Postfix) with ESMTP id 9BB30E31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 20:33:04 +0400 (MSD) Received: by mail.mivlgu.ru (Postfix, from userid 112) id 501FB81781; Tue, 8 Jul 2003 20:33:03 +0400 (MSD) Received: from vcserver.mivlgu.local (vcserver.mivlgu.local [192.168.1.251]) by mail.mivlgu.ru (Postfix) with SMTP id 222058177E; Tue, 8 Jul 2003 20:32:58 +0400 (MSD) Date: Tue, 8 Jul 2003 20:32:58 +0400 From: Sergey Vlasov <vsu@altlinux.ru> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Message-Id: <20030708203258.20e3cfc3.vsu@altlinux.ru> In-Reply-To: <87r851q99s.fsf@velvet.po.cs.msu.su> References: <m3n0fp5ed3.fsf@altlinux.ru> <87r851q99s.fsf@velvet.po.cs.msu.su> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: [d-kernel] Re: =?koi8-r?b?0NLP09jCwQ==?= X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 16:33:05 -0000 On Tue, 08 Jul 2003 20:21:35 +0400 Peter Novodvorsky <nidd@myxomop.com> wrote: > ed@altlinux.ru (Ed V. Bartosh) writes: > > > Hello, > > > > Просьба анонсить заливаемые в Сизиф новые пакеты/апдейты в этот > > список, желательно с описанием. > > > > Вот, например, что это такое и откуда ? > > kernel-modules-pctel-sis-std-up-0.9.6-alt1.i586.rpm > > kernel-source-pctel-0.9.6-0.9.6-alt1.noarch.rpm > > > > На списке про это ничего не было, насколько я знаю. > > Sorry, делал в спешке. Это драйвера для win-модемов в sis матерях, в > принципе оттуда же собираются ещё pctel драйвера, но так как они > называются точно так же, а конфликтов не хотелось, поэтому я пока > собираю только для sis. Это было очень нужно для одного нашего OEM > партнёра. Ага, а люди уже с этим pctel мучаются (см. sisyphus@). >From Egor.Orlov@avalon.ru Tue Jul 8 20:52:19 2003 Return-Path: <Egor.Orlov@avalon.ru> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 13079498FE for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 20:52:19 +0400 (MSD) Received: from smtp.avalon.ru (ns.avalon.ru [195.209.229.227]) by master.altlinux.ru (Postfix) with ESMTP id B5FFFE31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 20:52:18 +0400 (MSD) Received: from oes-buk.avalon.ru ([192.168.1.223]) by smtp.avalon.ru with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jul 2003 20:53:11 +0400 Date: Tue, 8 Jul 2003 20:52:30 +0400 From: "Egor S. Orlov" <Egor.Orlov@avalon.ru> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] Re: =?KOI8-R?Q?=D0=D2=CF=D3=D8=C2=C1?= Message-Id: <20030708205230.1e29011b.Egor.Orlov@avalon.ru> In-Reply-To: <20030708203258.20e3cfc3.vsu@altlinux.ru> References: <m3n0fp5ed3.fsf@altlinux.ru> <87r851q99s.fsf@velvet.po.cs.msu.su> <20030708203258.20e3cfc3.vsu@altlinux.ru> Organization: FST SPbSPU X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.u1H,EYvLUX8OFl" X-OriginalArrivalTime: 08 Jul 2003 16:53:11.0482 (UTC) FILETIME=[6A6041A0:01C34571] X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 16:52:19 -0000 --=.u1H,EYvLUX8OFl Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: base64 PiA+IA0KPiA+IFNvcnJ5LCDExczBzCDXINPQxdvLxS4g/NTPIMTSwcrXxdLBIMTM0SB3aW4tzc/E xc3P1yDXIHNpcyDNwdTF0tHILCDXDQo+ID4g0NLJzsPJ0MUgz9TU1cTBINbFINPPwsnSwcDU09Eg xd2jIHBjdGVsIMTSwcrXxdLBLCDOzyDUwcsgy8HLIM/OyQ0KPiA+IM7B2tnXwcDU09Eg1M/ezs8g 1MHLINbFLCDBIMvPzsbMycvUz9cgzsUgyM/UxczP09gsINDP3NTPzdUg0SDQz8vBDQo+ID4g08/C ydLBwCDUz8zYy88gxMzRIHNpcy4g/NTPIMLZzM8gz97FztggztXWzs8gxMzRIM/Ezs/HzyDOwdvF x88gT0VNDQo+ID4g0MHS1M6j0sEuIA0KPiANCj4g4cfBLCDBIMzAxMkg1dbFINMg3NTJzSBwY3Rl bCDN1d7BwNTT0SAo080uIHNpc3lwaHVzQCkuDQoNCtXH1SwgzdXewcXN09EgOikNCtDSwdfEwSDO xSDOwSDTydPP19PLz8osIMEgzsEgyc7UxczP19PLz8ogzcHUxdLJDQoNCi0tIA0KV0JSLCBFZ29y IFMuIE9ybG92DQpGU1QgU1BiU1BVDQo= --=.u1H,EYvLUX8OFl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/CvbO2ryY9MmM89IRAkU4AJwOT3425YVPRdF3uMUpi4BHVWNE9gCeJ8d5 tlZGMKTQZxnMH9OIOuI4OCo= =yGHh -----END PGP SIGNATURE----- --=.u1H,EYvLUX8OFl-- >From rider@altlinux.com Tue Jul 8 22:32:21 2003 Return-Path: <rider@altlinux.com> Delivered-To: devel-kernel@lrn.ru Received: from master.altlinux.ru (master.altlinux.ru [62.118.250.235]) by lrn.ru (Postfix) with ESMTP id 61085499DF for <devel-kernel@lrn.ru>; Tue, 8 Jul 2003 22:32:21 +0400 (MSD) Received: from riderbook.office.altlinux.ru (caltrop.alt.iph.ras.ru [194.67.87.71]) by master.altlinux.ru (Postfix) with ESMTP id 2AF89E31CF for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 22:32:21 +0400 (MSD) Received: from altlinux.com (localhost.localdomain [127.0.0.1]) by riderbook.office.altlinux.ru (Postfix) with ESMTP id 001C2C4EB for <devel-kernel@altlinux.ru>; Tue, 8 Jul 2003 22:01:34 +0400 (MSD) Message-ID: <3F0B06FE.60102@altlinux.com> Date: Tue, 08 Jul 2003 22:01:34 +0400 From: Anton Farygin <rider@altlinux.com> Organization: ALT Linux User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030627 X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] =?KOI8-R?Q?=F0=D2=CF_=D3=D4=CF=D2=CF=CE=CE=C9=C5?= =?KOI8-R?Q?_=CD=CF=C4=D5=CC=C9?= References: <200307081933.42674.morozov@novosoft.ru> In-Reply-To: <200307081933.42674.morozov@novosoft.ru> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1814331DE5B5701EDA56EC1F" Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> List-Id: ALT Linux kernel packages development <devel-kernel.altlinux.ru> List-Unsubscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=unsubscribe> List-Archive: </pipermail/devel-kernel> List-Post: <mailto:devel-kernel@altlinux.ru> List-Help: <mailto:devel-kernel-request@altlinux.ru?subject=help> List-Subscribe: <http://altlinux.ru/mailman/listinfo/devel-kernel>, <mailto:devel-kernel-request@altlinux.ru?subject=subscribe> X-List-Received-Date: Tue, 08 Jul 2003 18:32:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1814331DE5B5701EDA56EC1F Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Alexey Morozov пишет: > Неплохо было бы /заполучить/ механизм автоматического добавления в > modules.conf модулей, которые доставляются отдельными от ядра пакетами. > Наверное, можно было бы сделать нечто вроде /etc/modules.d/ в которую > складывать соответствующие кусочки модульных конфигураций, и которые бы > инклюдились из /etc/modules.conf (насколько я прочитал, сейчас нет механизма > "заинклюдить все файлы из некоторой директории"). Вообще, хочется, чтобы > этот механизм, с одной стороны, не тормозил, с другой - позволял обходиться > без того хардкорного shell-программирования, которое можно наблюдать, н-р, в > старом ауриаловском пакете. > > Да, кстати, я собрал (ну, за исключением /правильного/ автоматического > прописывания в modules.conf) ауриаловские модули в новой схеме. Если есть > желающие, отошлю оба (kernel-source-aureal и kernel-modules-aureal) спека. СТОП СТОП СТОП !!! Не в коем случае ничего нельзя прописывать в POST скриптах в modules.conf!!! Прошу это внести в policy. Для обновления modules.conf есть другой, более правильный механизм. На данный момент это kudzu. Т.е. - сначала определяется небоходимость внесения изменений в modules.conf и только потом вносятся сами изменения. Rgds, Rider P.S. Ответственный за базу данных ldetect-lst, по которой собственно и опеределяются необходимые модули - я. --------------enig1814331DE5B5701EDA56EC1F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Cwb+qohfd2vlwKsRAnN8AJwI0Ub7TBuy8dlEbR5ibsfMZFLDjwCgulXU qXIYhkwLbPxX3gs+z1T44Rk= =eBTt -----END PGP SIGNATURE----- --------------enig1814331DE5B5701EDA56EC1F--
Не пора ли как то свести все нитки развития в cvs дерево? Или это уже сделано? Просто по моему период тестов новой схемы подходит к концу, появилась принципиально новая функциональность типа поддержки раида на корне или наборов модулей, а разобраться, где, собственно, последние версии, ченжлоги посмотреть, чего покрутить можно уже трудно. Какие планы у альт? Со своей стороны скажу, что в пятницу наш сервер уезжает в релком, так что если нужен хостинг, cvs, ftp, rsync, то я готов это все дело предоставить.
[-- Attachment #1: Type: text/plain, Size: 667 bytes --] Алексей Любимов пишет: > Не пора ли как то свести все нитки развития в cvs дерево? > Или это уже сделано? > > Просто по моему период тестов новой схемы подходит к концу, появилась > принципиально новая функциональность типа поддержки раида на корне или > наборов модулей, а разобраться, где, собственно, последние версии, > ченжлоги посмотреть, чего покрутить можно уже трудно. > > Какие планы у альт? > Со своей стороны скажу, что в пятницу наш сервер уезжает в релком, так > что если нужен хостинг, cvs, ftp, rsync, то я готов это все дело > предоставить. Дима выйдет из отпуска - поднимет. Хостинг нам не нужен - сами можем предоставить ;-) Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
>>>>> "AF" == Anton Farygin writes:
>> Неплохо было бы /заполучить/ механизм автоматического добавления
>> в modules.conf модулей, которые доставляются отдельными от ядра
>> пакетами. Наверное, можно было бы сделать нечто вроде
>> /etc/modules.d/ в которую складывать соответствующие кусочки
>> модульных конфигураций, и которые бы инклюдились из
[...]
AF> СТОП СТОП СТОП !!!
AF> Не в коем случае ничего нельзя прописывать в POST скриптах в
AF> modules.conf!!!
AF> Прошу это внести в policy.
точно, нужно вносить в другие места, которые нужно придумать.
AF> Для обновления modules.conf есть другой, более правильный
AF> механизм. На данный момент это kudzu.
У меня суппер-пуппер крутой модуль, обслуживающий офигительный
рамдиск. Что делать с kudzu?
AF> Т.е. - сначала определяется небоходимость внесения изменений в
AF> modules.conf и только потом вносятся сами изменения.
--
Zhenja Kaluta ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3 856E 7EE8 52DE E6B7 8725
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --] Zhenja Kaluta пишет: >>>>>>"AF" == Anton Farygin writes: > > > >> Неплохо было бы /заполучить/ механизм автоматического добавления > >> в modules.conf модулей, которые доставляются отдельными от ядра > >> пакетами. Наверное, можно было бы сделать нечто вроде > >> /etc/modules.d/ в которую складывать соответствующие кусочки > >> модульных конфигураций, и которые бы инклюдились из > > [...] > > AF> СТОП СТОП СТОП !!! > > AF> Не в коем случае ничего нельзя прописывать в POST скриптах в > AF> modules.conf!!! > > AF> Прошу это внести в policy. > > точно, нужно вносить в другие места, которые нужно придумать. > > AF> Для обновления modules.conf есть другой, более правильный > AF> механизм. На данный момент это kudzu. > > У меня суппер-пуппер крутой модуль, обслуживающий офигительный > рамдиск. Что делать с kudzu? Ничего не надо делать... речь идет о модулях для железа, а не для программных реализаций всякой хрени. > > AF> Т.е. - сначала определяется небоходимость внесения изменений в > AF> modules.conf и только потом вносятся сами изменения. Ну и зачем его в modules.conf при установке пакета прописывать ? Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
>>>>> "AF" == Anton Farygin writes:
AF> Zhenja Kaluta пишет:
>>>>>>> "AF" == Anton Farygin writes:
>> >> Неплохо было бы /заполучить/ механизм автоматического
>> >> добавления в modules.conf модулей, которые доставляются
>> >> отдельными от ядра пакетами. Наверное, можно было бы сделать
>> >> нечто вроде /etc/modules.d/ в которую складывать
>> >> соответствующие кусочки модульных конфигураций, и которые бы
>> >> инклюдились из
>> [...]
>> AF> СТОП СТОП СТОП !!! Не в коем случае ничего нельзя
>> AF> прописывать в POST скриптах в
>> AF> modules.conf!!!
>> AF> Прошу это внести в policy.
>> точно, нужно вносить в другие места, которые нужно придумать.
>> AF> Для обновления modules.conf есть другой, более правильный
>> AF> механизм. На данный момент это kudzu.
>> У меня суппер-пуппер крутой модуль, обслуживающий офигительный
>> рамдиск. Что делать с kudzu?
AF> Ничего не надо делать... речь идет о модулях для железа, а не
AF> для программных реализаций всякой хрени.
Отлично! Никто ведь не мешает определить железо, положить
соответствующие куски в /etc/modules.d/ и позвать update-modules?
>> AF> Т.е. - сначала определяется небоходимость внесения
>> AF> изменений
>> в
>> AF> modules.conf и только потом вносятся сами изменения.
AF> Ну и зачем его в modules.conf при установке пакета прописывать ?
Чтобы он автоматически поднимался при обращении к обслуживаемому
устройству. Другой пример -- evms. Аналогичная ситуацию -- железные
девайсы есть одно, но ежели мы к ним полезем через major number 117,
получим уже совсем другую картину.
c /etc/modules.d/ получается более гибкая схема.
--
Zhenja Kaluta ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3 856E 7EE8 52DE E6B7 8725
[-- Attachment #1: Type: text/plain, Size: 405 bytes --] Господа, я предлагаю до того момента, пока не разрешится проблема с зависимостями ядер и apt-get'ом решить ее более радикально: из Sisyphus перенести в Daedalus все ядра, за исключением std-up ядра (и std-smp) и ядра 22. Это нужно сделать как можно быстрее, ибо в данный момент я не могу сформировать ни одного дистрибутива. Стас, убери плз все это из Sisyphus. Список я могу прислать. Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 984 bytes --] Anton Farygin пишет: > Господа, я предлагаю до того момента, пока не разрешится проблема с > зависимостями ядер и apt-get'ом решить ее более радикально: > > из Sisyphus перенести в Daedalus все ядра, за исключением std-up ядра (и > std-smp) и ядра 22. > > Это нужно сделать как можно быстрее, ибо в данный момент я не могу > сформировать ни одного дистрибутива. > > Стас, убери плз все это из Sisyphus. Список я могу прислать. > Вдогонку - почему это нужно сделать. Вот еще один пример и вопрос - что должен будет поставить apt-get по команде apt-get install NVIDIA_GLX ? [rider@altair RPMS]$ apt-cache whatdepends NVIDIA_kernel <NVIDIA_kernel> NVIDIA_GLX-1.0.4363-alt1 Требует: <NVIDIA_kernel> kernel-modules-nvidia-std-smp#1.0.4349-alt4-1.0.4349-alt4 kernel-modules-nvidia-std-up#1.0.4363-alt4-1.0.4363-alt4 kernel-modules-nvidia-w4l-smp#1.0.4349-alt3-1.0.4349-alt3 kernel-modules-nvidia-w4l-up#1.0.4349-alt3-1.0.4349-alt3 Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --] Anton Farygin пишет: > Anton Farygin пишет: > >> Господа, я предлагаю до того момента, пока не разрешится проблема с >> зависимостями ядер и apt-get'ом решить ее более радикально: >> >> из Sisyphus перенести в Daedalus все ядра, за исключением std-up ядра >> (и std-smp) и ядра 22. >> >> Это нужно сделать как можно быстрее, ибо в данный момент я не могу >> сформировать ни одного дистрибутива. >> >> Стас, убери плз все это из Sisyphus. Список я могу прислать. >> > > Вдогонку - почему это нужно сделать. > > Вот еще один пример и вопрос - что должен будет поставить apt-get по > команде apt-get install NVIDIA_GLX ? > [rider@altair RPMS]$ apt-cache whatdepends NVIDIA_kernel > <NVIDIA_kernel> > NVIDIA_GLX-1.0.4363-alt1 > Требует: <NVIDIA_kernel> > kernel-modules-nvidia-std-smp#1.0.4349-alt4-1.0.4349-alt4 > kernel-modules-nvidia-std-up#1.0.4363-alt4-1.0.4363-alt4 > kernel-modules-nvidia-w4l-smp#1.0.4349-alt3-1.0.4349-alt3 > kernel-modules-nvidia-w4l-up#1.0.4349-alt3-1.0.4349-alt3 Собственно говоря тем, кто поленился это сказать: [root@riderbook root]# apt-get install NVIDIA_GLX Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: kernel-image-std-smp#2.4.21rc1-alt3 kernel-modules-nvidia-std-smp#1.0.4349-alt4 The following NEW packages will be installed: NVIDIA_GLX kernel-image-std-smp#2.4.21rc1-alt3 kernel-modules-nvidia-std-smp#1.0.4349-alt4 0 packages upgraded, 3 newly installed, 0 removed and 0 not upgraded. Need to get 0B/13.5MB of archives. After unpacking 34.3MB of additional disk space will be used. Do you want to continue? [Y/n] [root@riderbook root]# rpm -qa|grep kernel-image kernel-image-2.4.21pre5-std-up-2.4.21pre5-alt1 kernel-image-std-up-2.4.21rel-alt3 kernel-image-2.4.21pre5-vanilla-2.4.21pre5-alt0.2 Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
On Thu, Jul 17, 2003 at 11:22:08AM +0400, Anton Farygin wrote: > Вот еще один пример и вопрос - что должен будет поставить > apt-get по команде apt-get install NVIDIA_GLX ? Кстати, пока помню: GLX-4363 и kernel-4349 прекрасно работают вместе (только что заметил, что последние N дней машинка так и загружена). Sidenote, слабо касающийся собственно разрешения проблемы. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
[-- Attachment #1: Type: text/plain, Size: 526 bytes --] On Sat, Jul 05, 2003 at 09:29:29PM +0700, Alexey Morozov wrote: > Тут еще один мелкий глючок в спеке (std-up, да и в остальных тоже): > > echo " > RPM { > Allow-Duplicated {"^kernel-image-%{flavour}$";}; > }; > " > $RPM_BUILD_ROOT/etc/apt/apt.conf.d/kernel-image-%{flavour}.conf > > делает не совсем то, что, как мне кажется, предполалось авторами. > По-моему, уместно написать По-моему, в /etc/apt/apt.conf.d/ плодить файлы совершенно неуместно. Тем более что в 0.5.5cnc4.1-alt5 был обновлён /etc/apt/apt.conf -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --] On Wed, Jul 09, 2003 at 12:13:00PM +0300, Zhenja Kaluta wrote: > >>>>> "MS" == Michael Shigorin writes: > > >> Неплохо было бы /заполучить/ механизм автоматического добавления > >> в modules.conf модулей, которые доставляются отдельными от ядра > >> пакетами. > > MS> Если я правильно понял tren -- в демьяне оно так и есть. > > Да. Механизм предельно прост: пакеты с модулями ядра кладут кусочек > /etc/modules.conf в каталог /etc/modutils. > Сейчас у меня там > > $ ls /etc/modutils > 0keep aliases arch input irda.dpkg-dist paths setserial usbcam > actions alsa-path evms irda net ppp sound > > Пример: > $ cat /etc/modutils/evms > alias block-major-117 dm-mod > > $ cat /etc/modutils/irda > alias tty-ldisc-11 irtty > alias char-major-161 ircomm-tty > alias char-major-60 ircomm_tty > > # for dongle > alias irda-dongle-0 tekram > alias irda-dongle-1 esi > alias irda-dongle-2 actisys > alias irda-dongle-3 actisys > alias irda-dongle-4 girbil > alias irda-dongle-5 litelink > alias irda-dongle-6 airport > alias irda-dongle-7 old_belkin > > # for FIR device > alias irda0 irda-usb > > Затем (из post-скриптов обычно) зовется /sbin/update-modules, который > формирует /etc/modules.conf и зовет depmod. > > Собственно, подобный механизм используется много где. Всё верно. И до modutils доберется прогресс. :) -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
> ide-disk. Если использовать vga=788, то в момент загрузки модуля для eth0.
Не пожалел ещё перезагрузок, выяснил следующее: если загрузиться без
поднятия интерфейса, то modprobe 3c59x отрабатывает нормально. Следующим
шагом ifup eth0 и немедленно получаю мёртвую систему. Это не
замораживание: сходил покурить, вернулся --- висит. Это
kernel-image-std-up-2.4.21rel-alt6
--
DO4-UANIC
>>>>> "DO" == Denis Ovsienko writes:
DO> Не пожалел ещё перезагрузок, выяснил следующее: если загрузиться
DO> без поднятия интерфейса, то modprobe 3c59x отрабатывает
DO> нормально. Следующим шагом ifup eth0 и немедленно получаю
DO> мёртвую систему. Это не замораживание: сходил покурить, вернулся
DO> --- висит. Это kernel-image-std-up-2.4.21rel-alt6
Попробуй пересобрать ядро, выкинув kernel-fix-drivers-net, возможно
поможет. Можно также попробовать не выбрасывать весь пакет, а только, скажем
02_3c59x.upgrade.patch откатить. Это поможет более тонко
продиагностировать ситуацию.
--
Best regards,
Ed V. Bartosh
> Попробуй пересобрать ядро, выкинув kernel-fix-drivers-net, возможно
> поможет. Можно также попробовать не выбрасывать весь пакет, а только, скажем
> 02_3c59x.upgrade.patch откатить. Это поможет более тонко
> продиагностировать ситуацию.
Я пока нашёл подходящую сборочно-проверочную станцию, сейчас ловлю музу :)
Попробую обязательно, потому что 3C905 у меня самые распространённые
интерфейсы.
--
DO4-UANIC
Здравствуйте! в связи с тем, что есть приложения, которые хотят алсу, причём произвольно какую, на LF было принято решение сделать пакет kernel-headers-alsa (просто), так как headers алсы не зависят от релиза, с которым была собрана alsa. Все headers гуськом отправляются в /usr/include/sound. Появится в Сизифе сегодня, в крайнем случае завтра, если тесты не пройдут успешно. А, забыл, надеюсь ни у кого нет возражений? В policy это, видимо, тоже придётся отразить. Заменить одно must на may. Nidd. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite!
[-- Attachment #1: Type: text/plain, Size: 323 bytes --] On Mon, Jul 28, 2003 at 05:55:26PM +0400, Peter Novodvorsky wrote: > в связи с тем, что есть приложения, которые хотят алсу, причём > произвольно какую, на LF было принято решение сделать пакет > kernel-headers-alsa (просто), так как headers алсы не зависят от > релиза, с которым была собрана alsa. Подтверждаю. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
On Mon, Jul 28, 2003 at 05:55:26PM +0400, Peter Novodvorsky wrote: > А, забыл, надеюсь ни у кого нет возражений? Не-а. В смысле, все OK :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
Здравствуйте. Созрел я для сборки ядер под свои конфигурации (для 3х машин: Пень 133 (не MMX) на SIS5511/12/13, Пень 3 на какомто из Intel и Атлон на nForce2). В общем виде данный процесс, в принципе понятен (статью http://www.atmsk.ru/viewtopic.php?t=903 читал). Но я запутался, с определением списка пакетов, которые надо вытянуть для корректной сборки ядра: 1. Непонял кокое ядро лучше взять за основу: aw или std (скорее всего std) под мои требования (см. ниже). 2. Слабо представляю что от чего зависит. Что я хочу получить в результате (основные позиции): 1. EVMS 2. Alsa 0.9.6 3. USB 4. Reiserfs 5. XFS 6. На платные сенсоры 7. Драйвера NVIDIA для nForce и видео карт. Как я понял из рассылки, aw и std ядра полностью данный список не покрывают. :-( Подскажите пожалуйста, что мне надо будет выкачать (из source, modules, feat, fix и т. д.) а то глаза разбегаются. :-) Спасибо за внимание. -- С уважением. Алексей.
>>>>> "AA" == Aleksey Avdeev writes: AA> Созрел я для сборки ядер под свои конфигурации (для 3х машин: AA> Пень 133 (не MMX) на SIS5511/12/13, Пень 3 на какомто из Intel AA> и Атлон на nForce2). В общем виде данный процесс, в принципе AA> понятен (статью http://www.atmsk.ru/viewtopic.php?t=903 AA> читал). Но я запутался, с определением списка пакетов, которые AA> надо вытянуть для корректной сборки ядра: Можно взять спек от kernel-image и посмотреть на то, какие патчи туда включаются (макрос %add_patch_list) - это будет список нужных пакетов kernel-feat и kernel-fix. Кроме того нужен kernel-source-<версия ядра> и kernel-build-tools. Почитайте полиси, оно лежит в kernel-build-tools, там кое-что об этом есть. AA> 1. Непонял кокое ядро лучше взять за основу: aw или std (скорее AA> всего std) под мои требования (см. ниже). На это могу сказать только об aw - среди затребованых фич в нем нет alsa,NVIDIA и Raiser-а. последний в принципе могу собрать модулем. AA> 2. Слабо представляю что от чего зависит. В смысле ? Все фичи включаются в спеке kernel-image с помощью вышеупомянутого макроса %add_patch_list. Остальные зависимости, да и эти тоже, видно обычным образом: rpm -q --requires AA> Что я хочу получить в результате (основные позиции): AA> 1. EVMS AA> 2. Alsa 0.9.6 AA> 3. USB AA> 4. Reiserfs AA> 5. XFS AA> 6. На платные сенсоры AA> 7. Драйвера NVIDIA для nForce и видео карт. AA> Как я понял из рассылки, aw и std ядра полностью данный список AA> не покрывают. :-( Ну да. В aw звук и видео и не планируется включать, оно сервер-ориентированное. А понимать это проще не из рассылки, а с помощью rpm :) AA> Подскажите пожалуйста, что мне надо будет выкачать (из source, AA> modules, feat, fix и т. д.) а то глаза разбегаются. :-) Дык это, схема ничем не отличается от других пакетов - все те же зависимости, вся информация доступна с помощью rpm: Берем kernel-image-std-up...src.rpm и смотрим, что ему нужно для сборки: [ed@pc213 kernel-source-2.4.21]$ rpm -qp --requires kernel-image-std-up-2.4.21rel-alt7.src.rpm ... kernel-source-2.4.21 = 1.0.0 kernel-build-tools kernel-fix-security-owl kernel-fix-security kernel-fix-build kernel-fix-drivers-ide kernel-fix-drivers-net kernel-fix-drivers-pci kernel-fix-drivers-scsi kernel-fix-drivers-usb kernel-fix-core kernel-fix-fs kernel-feat-core-O1sched kernel-feat-addon kernel-feat-acpi kernel-feat-i2c kernel-feat-fs-ntfs kernel-feat-fs-xfs kernel-feat-kconfig kernel-feat-crypto kernel-feat-drivers-video-splash kernel-feat-bttv kernel-feat-net-ppp-mppe kernel-feat-net-ipsec ... Выкачиваем и устанавливаем по этому списку все, что мы хотим включить в свое ядро. Точно так же и для модулей: rpm -qp --requires /mnt/Sisyphus/SRPMS.kernel/kernel-modules-alsa-std-up-0.9.6-alt1.src.rpm gcc2.96 modutils perl rpm >= 4.0.2-75 kernel-headers-std-up = 2.4.21rel-alt7 kernel-source-alsa-0.9.6 Например, для alsa выкачиваем kernel-source-alsa и, для примера, модуль для std-up: kernel-modules-alsa-std-up ... src.rpm Для nvidia и всего остального, что в модулях - аналогично. Для evms-а берем kernel-feat-dm и evms (kernel-feat-evms из одного спека с evms генерится). (это есть в ядре -aw, можно глянуть там) Raiser нужно будет просто включить, он в ядре уже есть. Когда все это добро у нас есть и установлено, то делаем на основе kernel-image-std (или любого другого kernel-image) спек(и) для kernel-image-наше_новое_ядро и пытаемся его собрать. потом точно так же поступаем с модулями. Вот и все вкратце. -- Best regards, Ed V. Bartosh
>> Выкачиваем и устанавливаем по этому списку все, что мы хотим >> включить в свое ядро. DO> apt-get build-dep это выполняет, я проверял ;) Я в курсе, но человек спросил чего выкачивать, мало ли что :) -- Best regards, Ed V. Bartosh
> Берем kernel-image-std-up...src.rpm и смотрим, что ему нужно для сборки: > [ed@pc213 kernel-source-2.4.21]$ rpm -qp --requires kernel-image-std-up-2.4.21rel-alt7.src.rpm > ... > kernel-source-2.4.21 = 1.0.0 [...] > kernel-feat-net-ipsec > ... > > Выкачиваем и устанавливаем по этому списку все, что мы хотим > включить в свое ядро. apt-get build-dep это выполняет, я проверял ;) -- DO4-UANIC
Denis Ovsienko пишет:
>>Берем kernel-image-std-up...src.rpm и смотрим, что ему нужно для сборки:
>>[ed@pc213 kernel-source-2.4.21]$ rpm -qp --requires kernel-image-std-up-2.4.21rel-alt7.src.rpm
>>...
>>kernel-source-2.4.21 = 1.0.0
>>
>>
>[...]
>
>
>>kernel-feat-net-ipsec
>>...
>>
>>Выкачиваем и устанавливаем по этому списку все, что мы хотим
>>включить в свое ядро.
>>
>>
>apt-get build-dep это выполняет, я проверял ;)
>
>
Что-то новое... :-) Можно поподробнее про build-dep: man apt-get её не
показал (Сизиф от 20030731)...
--
С уважением. Алексей.
Denis Ovsienko пишет: >>>>Выкачиваем и устанавливаем по этому списку все, что мы хотим >>>>включить в свое ядро. >>> >>>apt-get build-dep это выполняет, я проверял ;) >> >> Что-то новое... :-) Можно поподробнее про build-dep: man apt-get её не >>показал (Сизиф от 20030731)... > > [pilot@acara pilot]$ apt-get > apt 0.5.5cnc4.1 для linux i586 собран Jun 25 2003 19:08:05 > Использование: apt-get [параметры] команда > apt-get [параметры] install|remove пакет1 [пакет2 ...] > apt-get [параметры] source пакет1 [пакет2 ...] ... > Спасибо. Буду знать что так тоже можно! :-) (Всегда apt-get с командой пускал... :-))) PS: Приношу извинения за дубли. -- С уважением. Алексей.
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --] Всем привет. Предлагаю включать версию и релиз ядра, для которого собран пакет с модулем в версию пакета с модулем. Почему это нужно: для корректного отслеживания пакетов (по имени, а не по зависимостям), содержащих модули ядра. Пример: kernel-modules-pcmcia-cs-std-up в текущем Sisysphus непонятно для какого ядра собрано. Как это будет выглядеть: версия пакета включает версию и сборку ядра, пример было: kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.src.rpm стало: kernel-modules-pcmcia-cs-std-up-2.4.21rel-alt8-3.2.4-alt1.src.rpm Предлагаю включить изменения в policy. Пересборку пакетов с модулями готов взять на себя (если они все соберутся, конечно) ;-) Также: В CVS ушел набор скриптов для импорта пакетов из Sisyphus в CVS репозитарий (пока что без CVS commit), сборки бинарных пакетов feat и fix, сборки исходных пакетов feat и fix, сборки бинарного пакета kernel-image (до остального я еще не добрался, ядро медленно собирается). Скрипты пытаются отслеживать даты изменения файлов и каталогов и не производить сборку пакетов если 1) этот пакет уже есть 2) в CVS дереве пакета не было изменений Прошу тестировать. 1) Запустить import-sisyphus <путь к SRPMS.kernel> 2) сказать make rpms 3) Сказать ./buildkernel std-up (или любое другое ядро, например std-smp и т.д.) Rgds, Rider P.S. Из CVS временно убраны каталоги feat и fix в связи со сменой структуры репозитария [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 793 bytes --] On Mon, Aug 11, 2003 at 04:20:59PM +0400, Anton Farygin wrote: > Предлагаю включать версию и релиз ядра, для которого собран пакет с > модулем в версию пакета с модулем. > > Почему это нужно: для корректного отслеживания пакетов (по имени, а не > по зависимостям), содержащих модули ядра. > > Пример: kernel-modules-pcmcia-cs-std-up в текущем Sisysphus непонятно > для какого ядра собрано. Это не так: $ rpmquery -pR Sisyphus/files/i586/RPMS/kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.i586.rpm |fgrep kernel kernel-image-std-up = 2.4.21rel-alt8 > Как это будет выглядеть: версия пакета включает версию и сборку ядра, пример > было: kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.src.rpm > стало: kernel-modules-pcmcia-cs-std-up-2.4.21rel-alt8-3.2.4-alt1.src.rpm Мне не нравится. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
On Mon, Aug 11, 2003 at 04:28:58PM +0400, Dmitry V. Levin wrote: > On Mon, Aug 11, 2003 at 04:20:59PM +0400, Anton Farygin wrote: > > Предлагаю включать версию и релиз ядра, для которого собран пакет с > > модулем в версию пакета с модулем. > > > > Почему это нужно: для корректного отслеживания пакетов (по имени, а не > > по зависимостям), содержащих модули ядра. > > > > Пример: kernel-modules-pcmcia-cs-std-up в текущем Sisysphus непонятно > > для какого ядра собрано. > > Это не так: > $ rpmquery -pR Sisyphus/files/i586/RPMS/kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.i586.rpm |fgrep kernel > kernel-image-std-up = 2.4.21rel-alt8 Хотел тоже самое написать. > > > Как это будет выглядеть: версия пакета включает версию и сборку ядра, пример > > было: kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.src.rpm > > стало: kernel-modules-pcmcia-cs-std-up-2.4.21rel-alt8-3.2.4-alt1.src.rpm > > Мне не нравится. Мне тоже. -- / Alexander Bokovoy Interchangeable parts won't.
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --] Alexander Bokovoy пишет: > On Mon, Aug 11, 2003 at 04:28:58PM +0400, Dmitry V. Levin wrote: > >>On Mon, Aug 11, 2003 at 04:20:59PM +0400, Anton Farygin wrote: >> >>>Предлагаю включать версию и релиз ядра, для которого собран пакет с >>>модулем в версию пакета с модулем. >>> >>>Почему это нужно: для корректного отслеживания пакетов (по имени, а не >>>по зависимостям), содержащих модули ядра. >>> >>>Пример: kernel-modules-pcmcia-cs-std-up в текущем Sisysphus непонятно >>>для какого ядра собрано. >> >>Это не так: >>$ rpmquery -pR Sisyphus/files/i586/RPMS/kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.i586.rpm |fgrep kernel >>kernel-image-std-up = 2.4.21rel-alt8 > > Хотел тоже самое написать. Я про эту команду прекрасно знаю ;-) > > >>>Как это будет выглядеть: версия пакета включает версию и сборку ядра, пример >>>было: kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.src.rpm >>>стало: kernel-modules-pcmcia-cs-std-up-2.4.21rel-alt8-3.2.4-alt1.src.rpm >> >>Мне не нравится. > > Мне тоже. Почему ? На мой взгляд - вполне оправданная схема. В принципе - это не очень принципиально. Просто на мой взгляд было бы несколько удобнее наблюдать версию сборки ядра в имени пакета.;-) Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 827 bytes --] On Mon, Aug 11, 2003 at 04:58:53PM +0400, Anton Farygin wrote: > >>>Как это будет выглядеть: версия пакета включает версию и сборку ядра, > >>>пример > >>>было: kernel-modules-pcmcia-cs-std-up-3.2.4-alt1.src.rpm > >>>стало: kernel-modules-pcmcia-cs-std-up-2.4.21rel-alt8-3.2.4-alt1.src.rpm > >> > >>Мне не нравится. > > > >Мне тоже. > > Почему ? 1. Избыточная информация. 2. Неэстетично. > На мой взгляд - вполне оправданная схема. В принципе - это не > очень принципиально. Просто на мой взгляд было бы несколько удобнее > наблюдать версию сборки ядра в имени пакета.;-) В имени - нет. В версии - первичной является собственная версия пакета, а не ядра. Например, Sisyphus/files/i586/RPMS/rpm-python-4.0.4_2.2-alt22.i586.rpm (версия rpm = 4.0.4, major-версия python = 2.2) И даже в таком виде кажется лишним. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 968 bytes --] Всем привет ! Один вопрос: Как пользователь должен обновлять пакеты с ядрами? apt-get install kernel-image-std-up не обновляет все модули, которые были у него установлены а _стандартный_ пользователь может не знать какие у него стояли модули раньше... мало того - могут появится новые пакеты с модулями. Что делать ? Я опять предлагаю вернутся к старой схеме: один пакет - все модули. Либо доработать существующую в CVS схему сборки ядра (кто? мне сейчас совсем некогда) для того, что бы при сборке kernel-modules генерить пакет kernel-complete с зависимостями уже на version-release. Соостветственно после этого пакеты с ядрами, которые не вытаскивает ни один kernel-complete: убрать из Sisyphus. Также предлагаю жестко прописать расположение каталогов с модулями внутри kernel-image. В очередной сборке ядра оказался поломан pcmcia, ибо исчез катало /lib/modules/`uname -r`/pcmcia, из которого грузились ранее модули pcmcia_core и др. Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
>>>>> "AF" == Anton Farygin writes:
AF> Как пользователь должен обновлять пакеты с ядрами?
AF> apt-get install kernel-image-std-up не обновляет все модули,
AF> которые были у него установлены
apt-get upgrade разве не обновит те модули, которые установлены,
после установки соответствующего ядра ?
AF> а _стандартный_ пользователь может не знать какие у него стояли
AF> модули раньше... мало того - могут появится новые пакеты с
AF> модулями.
Могут появиться новые пакеты не только с модулями :) Их тоже того,
ставить ?
--
Best regards,
Ed V. Bartosh
[-- Attachment #1: Type: text/plain, Size: 924 bytes --] Ed V. Bartosh пишет: >>>>>>"AF" == Anton Farygin writes: > > > AF> Как пользователь должен обновлять пакеты с ядрами? > > AF> apt-get install kernel-image-std-up не обновляет все модули, > AF> которые были у него установлены > apt-get upgrade разве не обновит те модули, которые установлены, > после установки соответствующего ядра ? Нет. Вообще стандартно ядра устанавливаются через install. Это позволяет иметь старое и новое ядро одновременно. > > AF> а _стандартный_ пользователь может не знать какие у него стояли > AF> модули раньше... мало того - могут появится новые пакеты с > AF> модулями. > Могут появиться новые пакеты не только с модулями :) Их тоже того, > ставить ? Нет. речь идет только о пакетах с модулями. Еще один пример: nvidia_glx хочет ядерный пакет kernel-modules-nvidia В системе установлено одно ядро и пользователь ставит еще одно ядро, более новой версии. Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 805 bytes --] On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote: > Как пользователь должен обновлять пакеты с ядрами? Возможно, для этого стоит сделать отдельную тулзень, которая будет иметь достаточно специфический интеллект. Раздумий над вопросом было довольно много, и на пока мне кажется, что в рамках rpm/apt как _generic_ PM это не укладывается -- там и так хватает хаков вроде Hold и Allow-Duplicated. На статических зависимостях, которые не умеют "оглядываться" (например, новое ядро "видит" уже установленные к старому модули и начинает жаждать и себе) -- не вижу, как это делается. Будь они жесткими или "suggested". PS: запихивать все опять в один мешок -- фу. Лучше захакай эту ^&*(^(&^. :( -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 950 bytes --] Michael Shigorin пишет: > On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote: > >>Как пользователь должен обновлять пакеты с ядрами? > > > Возможно, для этого стоит сделать отдельную тулзень, которая > будет иметь достаточно специфический интеллект. Нет. Это не выход. > > Раздумий над вопросом было довольно много, и на пока мне кажется, > что в рамках rpm/apt как _generic_ PM это не укладывается -- там > и так хватает хаков вроде Hold и Allow-Duplicated. Да. > > На статических зависимостях, которые не умеют "оглядываться" > (например, новое ядро "видит" уже установленные к старому модули > и начинает жаждать и себе) -- не вижу, как это делается. Будь > они жесткими или "suggested". Да. > > PS: запихивать все опять в один мешок -- фу. Лучше захакай эту > ^&*(^(&^. :( Чем тебе не нравится kernel-complete ? Да, это хак. Но вполне разумный хак в данной ситуации (мы не можем быстро переписать apt-get) Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
>>>>> "Anton" == Anton Farygin <rider@altlinux.com> writes:
> Michael Shigorin пишет:
>> On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote:
>>
>>> Как пользователь должен обновлять пакеты с ядрами?
>> Возможно, для этого стоит сделать отдельную тулзень, которая
>> будет иметь достаточно специфический интеллект.
> Нет. Это не выход.
>> Раздумий над вопросом было довольно много, и на пока мне кажется,
>> что в рамках rpm/apt как _generic_ PM это не укладывается -- там
>> и так хватает хаков вроде Hold и Allow-Duplicated.
> Да.
>> На статических зависимостях, которые не умеют "оглядываться"
>> (например, новое ядро "видит" уже установленные к старому модули
>> и начинает жаждать и себе) -- не вижу, как это делается. Будь
>> они жесткими или "suggested".
> Да.
>> PS: запихивать все опять в один мешок -- фу. Лучше захакай эту
>> ^&*(^(&^. :(
> Чем тебе не нравится kernel-complete ? Да, это хак. Но вполне разумный
> хак в данной ситуации (мы не можем быстро переписать apt-get)
Тем, что это лекарство не лечит.
Смысл распиливания ядра был в т.ч. в том, чтобы иметь
возможность не ставить того, что не нужно, следовательно,
kernel-complete в значительной части инсталляций проставлен
не будет.
--
[-- Attachment #1: Type: text/plain, Size: 4123 bytes --] On Wed, Aug 13, 2003 at 04:25:00PM +0400, Anton Farygin wrote: > >>Как пользователь должен обновлять пакеты с ядрами? > >Возможно, для этого стоит сделать отдельную тулзень, которая > >будет иметь достаточно специфический интеллект. > Нет. Это не выход. Я ж написал "возможно". Не помню всех нюансов (и вообще сейчас меньше всего хочется думать о работе вообще и компьютерах в частности), но > >На статических зависимостях, которые не умеют "оглядываться" > > -- не вижу, как это делается. Будь они жесткими или > Да. (так чего споришь? :) > >PS: запихивать все опять в один мешок -- фу. Лучше захакай эту > >^&*(^(&^. :( > Чем тебе не нравится kernel-complete ? Да, это хак. Это хак, который кривее той цели, которую ты добиваешь. По крайней мере мне так сильно кажется. Т.е. для ряда ситуаций это выход (за который и я говорил, если ты помнишь), но навязывать такое гетто всем -- немногим лучше, чем тупо собирать все статически в ядро. > Но вполне разумный хак в данной ситуации (мы не можем быстро > переписать apt-get) Боюсь, дело даже не в апте. И еще раз повторю -- _мне_ *кажется*, что ситуация с ядром и модулями, будучи аппаратно-специфичной _и_ критичной для функционирования системы, требует просто отдельного разруливания. Смотри: - "просто так" обновлять ядро нельзя, потому что может не загрузиться как минимум -- на то есть Hold. - при обновлении и вообще для подстраховки рекомендуется иметь как минимум предыдущее работавшее ядро, следовательно, надо иметь возможность держать в системе несколько ядер, где под этим словом подразумевается комплект кода -- необязательно один пакет (это имеет место уже довольно давно). Это справляет Allow-Duplicated. При этом ломая возможность положиться на зависимости субпакетов при обновлении головного kernel-image. - около обновления выполняются пляски по обновлению конфигурации из %post (по минимуму depmod в субпакетах плюс более нетривиальные модификации симлинков и конфигурации загрузчика в головных пакетах) -- заметь, при росте количества наборов у нас есть +/- два выхода: * макросы/вспомогательные скрипты, которые дергаются заведомо однообразно (на сейчас это уже не так для kernel-image-std-up по сравнению с kernel24-up -- бардак с симлинками vmlinuz* и initrd*, думаю, все наблюдали минимум однажды); /это плохо. Потому, что любые изменения должны быть отражены в нескольких местах, а любые ошибки получают лишнюю возможность расползтись/ * инструмент, в который выносится та часть функциональности, которая, с одной стороны, достаточно общая для того, чтобы вынести ее из пакетов, и с другой стороны, достаточно "интеллектуальная" (выбор активного ядра), чтобы не возлагать ее на автомат. /если человек не хочет пользоваться этой штукой -- получит просто все на месте и initrd, но вот бутлоудером займется сам/ С учетом того, что вовсе не факт, что я собираюсь грузить свежеустановленное ядро, а также, возможно, не против _автоматической_ установки ядра, поступившего как sec update -- но БЕЗ настройки загрузчика на подъем именно его -- а также того, что такой важный процесс, как собственно конфигурирование этого самого загрузчика, не может иметь интерактивности в рамках %post -- мне еще раз кажется, что это отдельная софтина, которая может/обязана иметь особые отношения с: * kudzu (<-субпакеты), * apt (->обновления; установка?), * rpm (->установка?) -- нечто вроде select-gcc, который IMCO менее заслуживает вынесения за рамки alternatives, чем эта задача -- вынесения за рамки просто зависимостей и PM. Давай хоть сейчас нарисуем в первом приближении. Надо: - определить текущее ядро - получить список установленных пакетов с модулями, которые его требуют - проверить его на доступность в версиях, которые требуют устанавливаемое ядро С ходу непонятно, как что-то вроде `uname -r` преобразовать в SVR. PS: насчет sec updates -- понимаю, что высказано крайне сумбурно, но текущая ситуация, кажется, может быть улучшена. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --] On Wed, Aug 13, 2003 at 05:51:35PM +0400, Anton Farygin wrote: > >>Мне пришлось сделать такой хак в инсталяторе, ибо переписывать > >>текущий инсталятор в данный момент времени нет смысла. > >Антон, это все понятно, но это мухи, а не котлеты. Это проблема > >_инсталятора_, и если ломать и автогенить -- то его, а не все > >вокруг под тот же радиус загибать. Правда? > Неправда. У нас сейчас нет ресурсов для загибания всего и вся > под kernel Соотственно проще загнуть kernel подо все. <lyrics> Потом не будет ресурсов разогнуть, а потом в результате сгибания-разгибания корова наконец сдохнет. Видишь ли, это мы проходили не раз, и лично я последний раз -- вот за эти полгода. Тут тоже имели глупость избрать в какой-то момент времени такую "стратегию" и, понимаешъ, расхлебываем-с. </lyrics> По сути: чем отличается выгребание тобой зависимостей того же kernel-complete для инсталятора от такой же процедуры для каких-нибудь sh-utils? Ну не уразумею никак :( И объясни мне, что так драматически изменилось с тех пор, когда _уже_ был этот же инсталятор и как минимум kernel24-up и alsa24-up? -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2757 bytes --] Michael Shigorin пишет: > On Wed, Aug 13, 2003 at 05:51:35PM +0400, Anton Farygin wrote: > >>>>Мне пришлось сделать такой хак в инсталяторе, ибо переписывать >>>>текущий инсталятор в данный момент времени нет смысла. >>> >>>Антон, это все понятно, но это мухи, а не котлеты. Это проблема >>>_инсталятора_, и если ломать и автогенить -- то его, а не все >>>вокруг под тот же радиус загибать. Правда? >> >>Неправда. У нас сейчас нет ресурсов для загибания всего и вся >>под kernel Соотственно проще загнуть kernel подо все. > > > <lyrics> > Потом не будет ресурсов разогнуть, а потом в результате > сгибания-разгибания корова наконец сдохнет. > > Видишь ли, это мы проходили не раз, и лично я последний раз -- > вот за эти полгода. Тут тоже имели глупость избрать в какой-то > момент времени такую "стратегию" и, понимаешъ, расхлебываем-с. > </lyrics> > > По сути: чем отличается выгребание тобой зависимостей того же > kernel-complete для инсталятора от такой же процедуры для > каких-нибудь sh-utils? Ну не уразумею никак :( > > И объясни мне, что так драматически изменилось с тех пор, когда > _уже_ был этот же инсталятор и как минимум kernel24-up и > alsa24-up? Уже наверное в восьмой раз повторяю: в инсталяторе хардкорно прописываются модули для установки.. выглядет это так: push @{$o->{default_packages}}, "kernel-modules-alsa-std-up", "alsa2-utils", "aumix" if modules::get_al ias("sound-slot-0") =~ /^snd-/; push @{$o->{default_packages}}, "hsflinmodem", "kernel-modules-hsflinmodem-std-up" if grep { $_->{driver} eq 'hsfserial' } detect_devices::probeall(); push @{$o->{default_packages}}, "kernel-modules-slmdm-data", "kernel-modules-slmdm-std-up" if grep { $_->{driver} eq 'slamrmo' } detect_devices::probeall(); Вот теперь представь себе, что количество таких пакетов растет каждый день... Сейчас я сделал такой хак: push @{$o->{default_packages}}, "kernel-image-std-up", "kernel-modules-drm-std-up", "kernel-modules-slm dm-data", "kernel-modules-slmdm-std-up", "kernel-modules-bcm5700-std-up", "kernel-modules-pctel-std-up", "kernel -modules-sensors-std-up", "kernel-modules-nvidia-nforce-std-up" if !$::oem && c::kernel_version() =~ /^\Q2.4/; А kernel-complete не получается в инсталяторе использовать, т.к. у него конкретно сломана идеология работы с виртуальными пакетами и с зависимостями. Это лечится только переписыванием. Впрочем - если есть желание: можешь попробовать поправить (заодно исправив apt-get, kudzu и все остальное). Rgds, Rider P.S. Образ compact и installer с последними версиями XFree-4.3.0 и kernel-image-std-up закачивается на ftp.altlinux.ru/pub/people/rider/ISO/ Changelog приложен [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 926 bytes --] On Wed, Aug 13, 2003 at 07:40:29PM +0400, Anton Farygin wrote: > >И объясни мне, что так драматически изменилось с тех пор, когда > >_уже_ был этот же инсталятор и как минимум kernel24-up и > >alsa24-up? > Уже наверное в восьмой раз повторяю: Ну. > в инсталяторе хардкорно прописываются модули для установки.. > выглядет это так: Да. > Вот теперь представь себе, что количество таких пакетов растет > каждый день... Ты дистрибутив каждый день выпускаешь? > А kernel-complete не получается в инсталяторе использовать, Я помню, ты ж рассказывал. _Но_ не менее ли злым хаком будет ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как альтернативу установке kernel-complete, с которой инсталер не может справиться? Для данного конкретного выпуска (и его бет)? [этот кусок уйдет лично] > Changelog приложен Не-а :) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1195 bytes --] Michael Shigorin пишет: > On Wed, Aug 13, 2003 at 07:40:29PM +0400, Anton Farygin wrote: > >>>И объясни мне, что так драматически изменилось с тех пор, когда >>>_уже_ был этот же инсталятор и как минимум kernel24-up и >>>alsa24-up? >> >>Уже наверное в восьмой раз повторяю: > > > Ну. > > >>в инсталяторе хардкорно прописываются модули для установки.. >>выглядет это так: > > > Да. > > >>Вот теперь представь себе, что количество таких пакетов растет >>каждый день... > > > Ты дистрибутив каждый день выпускаешь? Да. > > >>А kernel-complete не получается в инсталяторе использовать, > > > Я помню, ты ж рассказывал. _Но_ не менее ли злым хаком будет > ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как > альтернативу установке kernel-complete, с которой инсталер не > может справиться? Для данного конкретного выпуска (и его бет)? А где взять список _всех_ ядерных пакетов ежедневно и желательно автоматом что бы это в инсталятор прописывалось ? Я могу конечно сделать совсем конкретный хак, типа apt-cache search kernel-|grep std-up и патчить этим инсталлер при каждой сборке.. но это уже такой конкретный хак ;-) И как же быть с apt-get и kudzu ? Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --] On Thu, Aug 14, 2003 at 03:03:30PM +0400, Anton Farygin wrote: > >>Вот теперь представь себе, что количество таких пакетов > >>растет каждый день... > >Ты дистрибутив каждый день выпускаешь? > Да. Нет. Это бета, а не дистрибутив. И время выпуска каждой беты у тебя есть конкретный набор таких пакетов. Мне тоже жаль, что тебе приходится это делать вручную. > >ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как > А где взять список _всех_ ядерных пакетов ежедневно и > желательно автоматом что бы это в инсталятор прописывалось ? Ммм... > Я могу конечно сделать совсем конкретный хак, типа apt-cache > search kernel-|grep std-up и патчить этим инсталлер при каждой > сборке.. но это уже такой конкретный хак ;-) Дык. Хотя, сдается мне, нечто вроде whatrequires kernel-image-std-up | grep ^kernel-module будет и то чище? Или тебя восхищает собственно патченье по мотивам репозитория? :] > И как же быть с apt-get и kudzu ? В плане приучения последнего к первому, что ли? Если действительно прибить гвоздями (безусловно устанавливать -- не вижу, чем это хуже запихивания всего в один (мета)пакет) -- для compact тебе это и не понадобится. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1925 bytes --] Michael Shigorin пишет: > On Thu, Aug 14, 2003 at 03:03:30PM +0400, Anton Farygin wrote: > >>>>Вот теперь представь себе, что количество таких пакетов >>>>растет каждый день... >>> >>>Ты дистрибутив каждый день выпускаешь? >> >>Да. > > > Нет. Это бета, а не дистрибутив. И время выпуска каждой беты у > тебя есть конкретный набор таких пакетов. > > Мне тоже жаль, что тебе приходится это делать вручную. Жалость мне не помошник ;-) > > >>>ПРОСТО ПРИБИТЬ ГВОЗДЯМИ установку ВСЕХ ядерных пакетов как >> >>А где взять список _всех_ ядерных пакетов ежедневно и >>желательно автоматом что бы это в инсталятор прописывалось ? > > > Ммм... > > >>Я могу конечно сделать совсем конкретный хак, типа apt-cache >>search kernel-|grep std-up и патчить этим инсталлер при каждой >>сборке.. но это уже такой конкретный хак ;-) > > > Дык. Хотя, сдается мне, нечто вроде whatrequires > kernel-image-std-up | grep ^kernel-module будет и то чище? [rider@riderbook rider]$ rpm -q --whatrequires kernel-image-std-up kernel-modules-alsa-std-up-0.9.4-alt4 kernel-modules-alsa-std-up-0.9.6-alt6 kernel-modules-sensors-std-up-2.8.0-alt4 Это все. В общем это не решение. > > Или тебя восхищает собственно патченье по мотивам репозитория? :] Мне нужно решение, максимально снижающее трудозатраты на разработку. И максимально облегчающее жизнь инкамингерам и мантейнерам ядра. > > >>И как же быть с apt-get и kudzu ? > > > В плане приучения последнего к первому, что ли? Если > действительно прибить гвоздями (безусловно устанавливать -- не > вижу, чем это хуже запихивания всего в один (мета)пакет) -- для > compact тебе это и не понадобится. Нет. В плане приученья kudzu вытаскивать нужные пакеты с модулями для найденного оборудования и apt-get - в плане корректного upgrade ядра вместе с установленными модулями (тут nidd вчера нашептал Lua, но тогда нужно apt-get перетаскивать из daedalus в Sisyphus) Rgds, Rider [-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1256 bytes --] On Thu, Aug 14, 2003 at 05:43:24PM +0400, Anton Farygin wrote: > [rider@riderbook rider]$ rpm -q --whatrequires kernel-image-std-up > kernel-modules-alsa-std-up-0.9.4-alt4 > kernel-modules-alsa-std-up-0.9.6-alt6 Выбираем старшего. > kernel-modules-sensors-std-up-2.8.0-alt4 > Это все. В общем это не решение. А может, все-таки пофиксить субпакеты, которые не хотят ядро, хотя должны бы? > >>И как же быть с apt-get и kudzu ? > >В плане приучения последнего к первому, что ли? > Нет. В плане приученья kudzu вытаскивать нужные пакеты с > модулями для найденного оборудования "Вытаскивать" -- откуда? Сейчас оно вроде urpmi для этого пользовало? (давно не наблюдал) > и apt-get - в плане корректного upgrade ядра вместе с > установленными модулями (тут nidd вчера нашептал Lua, но тогда > нужно apt-get перетаскивать из daedalus в Sisyphus) Ладно, пас. > >Если действительно прибить гвоздями (безусловно устанавливать > >-- не вижу, чем это хуже запихивания всего в один (мета)пакет) > >-- для compact тебе это и не понадобится. ? PS: можно, конечно, в новые ядра писать, что они Obsoletes: старые kernel-module-* (все для своего flavour) -- но :(( -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 659 bytes --] On Wed, Aug 13, 2003 at 12:15:56PM +0400, Anton Farygin wrote: > Как пользователь должен обновлять пакеты с ядрами? Лучше всего, если для этого будет достаточно стандартного apt-get dist-upgrade > apt-get install kernel-image-std-up не обновляет все модули, которые > были у него установлены > > а _стандартный_ пользователь может не знать какие у него стояли модули > раньше... мало того - могут появится новые пакеты с модулями. > > Что делать ? Для начала, немного подождать новой версии apt-rpm, в которой, скорее всего, появится соответствующая функциональность: http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-August/001933.html -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Я тут пытаюсь собрать пару дополнений к ядру... RTAI (www.rtai.org) и Comedi (www.comedi.org). Но есть одна проблема (вообще проблем много, но те хоть понятно как решать, вроде... :-) ). Один модуль из RTAI требует для сборки хедеры из Comedi, а Comedi для сборки требует хедеры RTAI. Как быть? Заранее спасибо за помощь. -- Юрий А. Зотов
Yura Zotov <yz@altlinux.ru> writes: > Я тут пытаюсь собрать пару дополнений к ядру... > > RTAI (www.rtai.org) и Comedi (www.comedi.org). > > Но есть одна проблема (вообще проблем много, но те хоть понятно > как решать, вроде... :-) ). Один модуль из RTAI требует для сборки > хедеры из Comedi, а Comedi для сборки требует хедеры RTAI. Как > быть? Возможно, стоит сделать так, чтобы сборка одного зависила от source пакета другого и наоборот. при сборке достаются нужные хедеры из source tgz чужого модуля. Nidd. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite!
On Sun, Aug 17, 2003 at 10:32:11AM +0400, Peter Novodvorsky wrote:
>
> Yura Zotov <yz@altlinux.ru> writes:
>
> > Я тут пытаюсь собрать пару дополнений к ядру...
> >
> > RTAI (www.rtai.org) и Comedi (www.comedi.org).
> >
> > Но есть одна проблема (вообще проблем много, но те хоть понятно
> > как решать, вроде... :-) ). Один модуль из RTAI требует для сборки
> > хедеры из Comedi, а Comedi для сборки требует хедеры RTAI. Как
> > быть?
>
> Возможно, стоит сделать так, чтобы сборка одного зависила от source
> пакета другого и наоборот. при сборке достаются нужные хедеры из
> source tgz чужого модуля.
А можно при подготовке source пакета для comedi сразу выделять
из него kernel-headers-comedi и устанавливать их зразу куда
положено? Кстати, их надо устанавливать в дерево хедеров ядра.
Это нормально?
--
Юрий А. Зотов
Yura Zotov <yz@altlinux.ru> writes: > On Sun, Aug 17, 2003 at 10:32:11AM +0400, Peter Novodvorsky wrote: >> >> Yura Zotov <yz@altlinux.ru> writes: >> >> > Я тут пытаюсь собрать пару дополнений к ядру... >> > >> > RTAI (www.rtai.org) и Comedi (www.comedi.org). >> > >> > Но есть одна проблема (вообще проблем много, но те хоть понятно >> > как решать, вроде... :-) ). Один модуль из RTAI требует для сборки >> > хедеры из Comedi, а Comedi для сборки требует хедеры RTAI. Как >> > быть? >> >> Возможно, стоит сделать так, чтобы сборка одного зависила от source >> пакета другого и наоборот. при сборке достаются нужные хедеры из >> source tgz чужого модуля. > > А можно при подготовке source пакета для comedi сразу выделять > из него kernel-headers-comedi и устанавливать их зразу куда > положено? Кстати, их надо устанавливать в дерево хедеров ядра. > Это нормально? В дерево хедеров ядра нельзя -- ведь неизвестно, в какое дерево оно попадёт. alsa-headers генерятся прямо из source, но они кладутся в /usr/include/sound. -- Peter Novodvorsky nidd@myxomop.com http://people.altlinux.ru/~nidd Deadheads, unite!
On Sun, Aug 17, 2003 at 02:47:30PM +0400, Peter Novodvorsky wrote:
> Yura Zotov <yz@altlinux.ru> writes:
>
> > On Sun, Aug 17, 2003 at 10:32:11AM +0400, Peter Novodvorsky wrote:
> >>
> >> Yura Zotov <yz@altlinux.ru> writes:
> >>
> >> > Я тут пытаюсь собрать пару дополнений к ядру...
> >> >
> >> > RTAI (www.rtai.org) и Comedi (www.comedi.org).
> >> >
> >> > Но есть одна проблема (вообще проблем много, но те хоть понятно
> >> > как решать, вроде... :-) ). Один модуль из RTAI требует для сборки
> >> > хедеры из Comedi, а Comedi для сборки требует хедеры RTAI. Как
> >> > быть?
> >>
> >> Возможно, стоит сделать так, чтобы сборка одного зависила от source
> >> пакета другого и наоборот. при сборке достаются нужные хедеры из
> >> source tgz чужого модуля.
> >
> > А можно при подготовке source пакета для comedi сразу выделять
> > из него kernel-headers-comedi и устанавливать их зразу куда
> > положено? Кстати, их надо устанавливать в дерево хедеров ядра.
> > Это нормально?
>
> В дерево хедеров ядра нельзя -- ведь неизвестно, в какое дерево оно
> попадёт. alsa-headers генерятся прямо из source, но они кладутся в
> /usr/include/sound.
Как это не известно? Я их буду класть только в дерево ядра,
которое соберу. В другом ядре они просто не будут работать.
В общем, я попробую переместить их в другое место...
--
Юрий А. Зотов
Решил разобрать/удалить старые ядра из системы... были почти все начиная с коробочного ALM 2.2 плюс w4l, llc В первый раз забыл скинуть лог... Сейчас: [john@yugov john]$ sudo apt-get remove kernel-image-std-up#2.4.21rel-alt8 Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено Следующие пакеты будут УДАЛЕНЫ: kernel-image-std-up#2.4.21rel-alt8 kernel-modules-alsa-std-up#0.9.6-alt2 kernel-modules-nvidia-std-up#1.0.4496-alt2 kernel-modules-sensors-std-up#2.7.0-alt7 0 пакетов будет обновлено и 0 новых установлено, 4 пакетов будет удалено и 2 не будет обновлено. Необходимо получить 0B архивов. После распаковки будет освобождено 29,7MB дискового пространства. Продолжить? [Y/n] Запуск RPM (/bin/rpm -e --fancypercent --nodeps)... /boot / / not removing entry, entry doen't exists depmod: Can't read /boot/System.map-2.4.21rel-std-up-alt8 ошибка: ошибка выполнения сценария %postun из kernel-modules-nvidia-std-up-1.0.4496-alt2, код возврата 1 depmod: Can't read /boot/System.map-2.4.21rel-std-up-alt8 /root/tmp/rpm-tmp.60866: line 2: 2.4.21rel-std-up-alt8: command not found ошибка: ошибка выполнения сценария %postun из kernel-modules-alsa-std-up-0.9.6-alt2, код возврата 127 depmod: Can't read /boot/System.map-2.4.21rel-std-up-alt8 ошибка: ошибка выполнения сценария %postun из kernel-modules-sensors-std-up-2.7.0-alt7, код возврата 1 причем после первой чистки сломались ссылки: /boot/vmlinuz /boot/initrd.img /boot/initrd-up.img Указывали на несуществующие ядра. Сейчас тоже не фонтан: [john@yugov john]$ sudo ls -al /boot | egrep 'vmlinuz|initrd|System.map' initrd-2.4.21-llc-up-alt2.img initrd-2.4.21rel-std-up-alt11.img initrd-2.4.21rel-std-up-alt12.img initrd-2.4.21rel-std-up-alt13.img initrd-2.4.21-w4l-up-alt4.img initrd.img -> initrd-2.4.21rel-std-up-alt13.img initrd-up.img -> initrd-2.4.21rel-std-up-alt8.img System.map -> System.map-2.4.21rel-std-up-alt12 System.map-2.4.21-llc-up-alt2 System.map-2.4.21rel-std-up-alt11 System.map-2.4.21rel-std-up-alt12 System.map-2.4.21rel-std-up-alt13 System.map-2.4.21-w4l-up-alt4 vmlinuz -> vmlinuz-2.4.21rel-std-up-alt13 vmlinuz-2.4.21-llc-up-alt2 vmlinuz-2.4.21rel-std-up-alt11 vmlinuz-2.4.21rel-std-up-alt12 vmlinuz-2.4.21rel-std-up-alt13 vmlinuz-2.4.21-w4l-up-alt4 vmlinuz-up -> vmlinuz-2.4.21rel-std-up-alt8 Причем записи о ядрах w4l и llc из /boot/grub/menu.lst исчезли! -- With Best regards, Evgeny Yugov, MTS, programmer of Advanced Technologies Departament. Registered Linux User #316667 mailto:yugov@scs-900.ru
Кто будет собирать следующие релизы ядер, пожалуйста проставьте "Provides: CryptoAPI-kernel" where applicable, чтобы я мог позднее навесить соответствующий Requires. -- DO4-UANIC
Господа, привет. Залито в i/S/ 84581d03d549729ee62e8ddd5d615163 kernel-modules-pentanet-std-smp-2.3.1-alt1.src.rpm c607e7886692bd75f29da0e5add75496 kernel-modules-pentanet-std-up-2.3.1-alt1.src.rpm 712c6be857e97842d253e04dc5ea6c28 kernel-source-pentanet-2.3.1-2.3.1-alt1.src.rpm ^ Это поддержка Pent@NET в виде модуля, управляющей программы и net-скриптов. Что-то из этого знающие люди втащат в kernel CVS. 35610adc9b9a387bcdcfd67e998631d ipsecadm-0.9-alt3.src.rpm ^ Это исправление net-скриптов для ipsectun-интерфейсов для корректной обработки static & default routes. -- DO4-UANIC
> ^ Это поддержка Pent@NET в виде модуля, управляющей программы и
> net-скриптов. Что-то из этого знающие люди втащат в kernel CVS.
Перезалито в виде alt2 по рекомендациям vsu
--
DO4-UANIC
[-- Attachment #1: signed data --] [-- Type: text/plain, Size: 160 bytes --] Господа, можно где-нибудь достать, например, спек от kernel-source-2.4.22, кроме как в .срц.рпм? Ибо неохота сливать. -- Best regards, wRAR ALT Linux Team [-- Attachment #2: signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Приветствую! Расскажите мне, как объяснить сборочной системе собрать новые версии ядерных модулей, не дожидаясь следующей сборки ядра? Конкретно вопрос про модули kernel-modules-hostap-{up-smp}. В версии, что сейчас в Сизифе обнаружены ошибки, от чего работа с радиокартами достаточно нестабильна, а на дворе уже 0.1.2 имеется с фиксами.
[-- Attachment #1: Type: text/plain, Size: 566 bytes --] On Mon, Nov 03, 2003 at 10:17:12PM +0800, Alexei Takaseev wrote: > Приветствую! > > Расскажите мне, как объяснить сборочной системе собрать новые версии > ядерных модулей, не дожидаясь следующей сборки ядра? Конкретно вопрос > про модули kernel-modules-hostap-{up-smp}. В версии, что сейчас в Сизифе > обнаружены ошибки, от чего работа с радиокартами достаточно нестабильна, > а на дворе уже 0.1.2 имеется с фиксами. Пнуть "сборочную систему", указав, что надо пересобрать :) Пока что только так. Кстати, а где соответствующий kernel-source-hostap - уже в пути? [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
On Mon, 3 Nov 2003 17:28:17 +0300
Sergey Vlasov <vsu@altlinux.ru> wrote:
> On Mon, Nov 03, 2003 at 10:17:12PM +0800, Alexei Takaseev wrote:
> > Приветствую!
> >
> > Расскажите мне, как объяснить сборочной системе собрать новые версии
> > ядерных модулей, не дожидаясь следующей сборки ядра? Конкретно
> > вопрос про модули kernel-modules-hostap-{up-smp}. В версии, что
> > сейчас в Сизифе обнаружены ошибки, от чего работа с радиокартами
> > достаточно нестабильна, а на дворе уже 0.1.2 имеется с фиксами.
>
> Пнуть "сборочную систему", указав, что надо пересобрать :)
>
> Пока что только так.
>
> Кстати, а где соответствующий kernel-source-hostap - уже в пути?
Ага, уже в инкоминге дожидается.
Hello devel-kernel, Подскажите, как собрать ядро из src.rpm в новой системе исходников ядра. В двух словах последовательность действий. Или подскажите, может где описание есть? -- Best regards, Alexei V. Mezin mailto:mezin@ntmdt.ru
On Sun, Nov 16, 2003 at 04:13:29PM +0300, Alexei V. Mezin wrote: > Подскажите, как собрать ядро из src.rpm в новой системе исходников > ядра. В двух словах последовательность действий. Или подскажите, > может где описание есть? http://velvet.po.cs.msu.su/~nidd/altlinux/here-is-not-there.txt http://velvet.po.cs.msu.su/~nidd/altlinux/kernel-policy.txt http://atmsk.ru -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
Здравствуйте! С Новым Годом всех Вас! Да пусть сопутствуют Нам Счастье и Удача! :-) -- С уважением. Алексей.
Берем к примеру - ftp://ftp.altlinux.ru/pub/people/ed/kernel-2.6.1/kernel-source-2.6.1-1.0.0-alt1.noarch.rpm И что с ним дальше делать ? Я пробывал с kernel-2.6.0 - от того же ED: брал спек - kerlnel-std-up.spec - из cvs репозитория АЛЬТа правил его под себя - строки с ошибками колментировал собрал - ядро запустилось - но автоматом не подхватывает ни один модуль и ругается kernel: Cannot read proc file system: 1 - Operation not permitted. Пробывал бинарники того-же ядра - от того же производителя - оно не грузит ниодин модуль при lsmod\modprobe - ругается на нехватку памяти ... -- Silence in xmms ---- Jaa mata, Net administrator JSC "Giprosvyaz" Andrey A. Jelnin aka BsoD e-mail: <bsod@gs7.ru> jabber: bsod@jabber.ru icq: 112600159
[-- Attachment #1: Type: text/plain, Size: 941 bytes --] On Fri, Jan 23, 2004 at 12:10:16PM +0400, Andrey A. Jelnin wrote: > Берем к примеру - > ftp://ftp.altlinux.ru/pub/people/ed/kernel-2.6.1/kernel-source-2.6.1-1.0.0-alt1.noarch.rpm > И что с ним дальше делать ? > > Я пробывал с kernel-2.6.0 - от того же ED: > брал спек - kerlnel-std-up.spec - из cvs репозитория АЛЬТа Надо было с Эдовского же ФТП. > собрал - ядро запустилось - но автоматом не подхватывает ни один модуль modutils оттуда же > и ругается kernel: Cannot read proc file system: 1 - Operation not permitted. Убрать в /etc/sysconfig/syslogd последние 2 ключа (должно остаться '-u syslogd -j /var/resolv'). > Пробывал бинарники того-же ядра - от того же производителя - оно не грузит ниодин модуль > при lsmod\modprobe - ругается на нехватку памяти ... modutils -- WBR, wRAR (ALT Linux Team) Если у библиотеки есть хотя бы один мотивированный пользователь в /bin или /sbin, то она должна находиться в /lib. -- ldv in devel@ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
> Надо было с Эдовского же ФТП. Где лежит ? Я тормоз - не нашел.... > > Пробывал бинарники того-же ядра - от того же производителя - оно не грузит ниодин модуль > > при lsmod\modprobe - ругается на нехватку памяти ... > modutils Я их тоже проапдейтил - на те что были вместе с ядром в одной директории на фтп -- Silence in xmms ---- Jaa mata, Net administrator JSC "Giprosvyaz" Andrey A. Jelnin aka BsoD e-mail: <bsod@gs7.ru> jabber: bsod@jabber.ru icq: 112600159
[-- Attachment #1: Type: text/plain, Size: 743 bytes --] On Fri, Jan 23, 2004 at 01:04:33PM +0400, Andrey A. Jelnin wrote: > > Надо было с Эдовского же ФТП. > Где лежит ? > Я тормоз - не нашел.... kernel-image.src.rpm > > > Пробывал бинарники того-же ядра - от того же производителя - оно не грузит ниодин модуль > > > при lsmod\modprobe - ругается на нехватку памяти ... > > modutils > Я их тоже проапдейтил - на те что были вместе с ядром в одной директории на фтп Ой, не заметил про "нехватку памяти". Если modutils точно последняя версия - ругаться. Если нет - обновлять. Последние несколько сборок этой ошибки не имеют (раньше, действительно, было такое). -- WBR, wRAR (ALT Linux Team) [...] собираемость sandman'ом гарантирует собираемость hasher'ом не менее чем на 90%. -- ldv in devel@ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
On Fri, Jan 23, 2004 at 01:04:33PM +0400, Andrey A. Jelnin wrote:
>> modutils
AAJ> Я их тоже проапдейтил - на те что были вместе с ядром в одной директории на фтп
uname -a
rpm -q modutils
cat /proc/modules
что говорят?
--
Gleb Stiblo AKA UlfR <g.stiblo@sam-solutions.net>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --] > uname -a Linux host.domain 2.6.0-std-up-alt1 #1 Fri Jan 23 09:04:27 SAMT 2004 i686 unknown unknown GNU/Linux > rpm -q modutils modutils-2.4.25-alt16 > cat /proc/modules parport_pc 39692 0 - Live 0xd08fd000 parport 42432 1 parport_pc, Live 0xd08f1000 agpgart 32716 0 - Live 0xd0836000 rtc 12872 0 - Live 0xd0806000 Ещё - прилагаю dmesg Я понимаю, что информация может быть ненужной - тк уже вроде бы перешли на 2.6.1, но вдруг -- Silence in xmms ---- Jaa mata, Net administrator JSC "Giprosvyaz" Andrey A. Jelnin aka BsoD e-mail: <bsod@gs7.ru> jabber: bsod@jabber.ru icq: 112600159 [-- Attachment #2: config.gz --] [-- Type: application/x-gzip, Size: 8446 bytes --] [-- Attachment #3: dmesg260.gz --] [-- Type: application/x-gzip, Size: 2998 bytes --]
> Ой, не заметил про "нехватку памяти". Если modutils точно последняя версия
> - ругаться. Если нет - обновлять. Последние несколько сборок этой ошибки
> не имеют (раньше, действительно, было такое).
Тут я немного напутал - ибо сегодня проапдейтил modutils до 16 релиза
и действительно эта ошибка пропала
Осталось только проблема с тем что автоматом не грузяться модули - те не поднимается
eth sound и тп
К слову - я собирал ядро с gcc-2.95
при 2.96 - оно выпадало при build fs/proc/array.c - если я что-то не путаю
гугль говорил, что этот проблема 2.96го компиллера
--
Silence in xmms
----
Jaa mata,
Net administrator JSC "Giprosvyaz" Andrey A. Jelnin aka BsoD
e-mail: <bsod@gs7.ru>
jabber: bsod@jabber.ru
icq: 112600159
On Fri, Jan 23, 2004 at 01:33:44PM +0400, Andrey A. Jelnin wrote: AR>> Ой, не заметил про "нехватку памяти". Если modutils точно последняя версия AR>> - ругаться. Если нет - обновлять. Последние несколько сборок этой ошибки AR>> не имеют (раньше, действительно, было такое). AAJ> AAJ> Тут я немного напутал - ибо сегодня проапдейтил modutils до 16 релиза AAJ> и действительно эта ошибка пропала AAJ> AAJ> Осталось только проблема с тем что автоматом не грузяться модули - те не поднимается AAJ> eth sound и тп Поставить оттуда же startup, заодно bootloader-utils и mkinitrd AAJ> К слову - я собирал ядро с gcc-2.95 AAJ> при 2.96 - оно выпадало при build fs/proc/array.c - если я что-то не путаю AAJ> гугль говорил, что этот проблема 2.96го компиллера А почему не 3.3? -- Gleb Stiblo AKA UlfR <g.stiblo@sam-solutions.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Осталось только проблема с тем что автоматом не грузяться модули - те не
> поднимается eth sound и тп
Та же беда, только собиралось gcc3.3-3.3.3-alt0.1
- --
Sin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAEO8IHC/AO6kh2soRAppnAKCZeS3cFTDUlnxS0zcuJgyYacB0DwCgiw9Y
eOmdKrIEKjiqJaNkQ+5GD14=
=DPCZ
-----END PGP SIGNATURE-----
> Поставить оттуда же startup, заодно bootloader-utils и mkinitrd Их - ну чтож вы в меня не верите то - хотя это я наверное просто не всё написал ^_- bootloader-utils и mkinitrd - нормально поставились... а вот startup-0.7-alt2 - не хочет - ошибка: неудовлетворенные зависимости: service >= 0.0.2-alt1 нужен для startup-0.7-alt2 hwclock >= 2.23-alt1 нужен для startup-0.7-alt2 xinitrc < 0:2.4.13-alt1 конфликтует с startup-0.7-alt2 kernel-headers-common < 0:1.1 конфликтует с startup-0.7-alt2 У меня ALM 2.2 - hwclock с ним ещё - более менее понятно - можно видимо из сизифа собрать. Пакет service присутствует в базе данных, но не имеет версии... Как поинимать ? И как разрешить конфликты? > А почему не 3.3? Ну в АЛМ 2.2 - штатно только 3.2 - где взять сборку 3.3 ? -- Silence in xmms ---- Jaa mata, Net administrator JSC "Giprosvyaz" Andrey A. Jelnin aka BsoD e-mail: <bsod@gs7.ru> jabber: bsod@jabber.ru icq: 112600159
[-- Attachment #1: Type: text/plain, Size: 844 bytes --] On Fri, Jan 23, 2004 at 01:55:12PM +0400, Andrey A. Jelnin wrote: > а вот startup-0.7-alt2 - не хочет - > > ошибка: неудовлетворенные зависимости: > service >= 0.0.2-alt1 нужен для startup-0.7-alt2 > hwclock >= 2.23-alt1 нужен для startup-0.7-alt2 > xinitrc < 0:2.4.13-alt1 конфликтует с startup-0.7-alt2 > kernel-headers-common < 0:1.1 конфликтует с startup-0.7-alt2 > > У меня ALM 2.2 - hwclock с ним ещё - более менее понятно - можно видимо из сизифа собрать. Кстати да. На днях хотел посоветовать знакомому поставить на ALJ2.2 startup-0.7-alt2, потом вспомнил, чем это кончится... Обсизифливанием. Точнее, обновиться придется по части инитскриптов (а это немало и м.б. чревато) -- WBR, wRAR (ALT Linux Team) Предлагаю прежде чем разрабатывать программу установки - написать руководство пользователя по ней. -- rider in devel@ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Привет All. Захотел поставить VMWare и удивился: Your kernel was built with "gcc" version "2.96", while you are trying to use "/usr/bin/gcc" version "3.3.3". This configuration is not supported and VMware Workstation cannot work in such configuration. Please either recompile your kernel with "/usr/bin/gcc" version "3.3.3", or restart /usr/bin/vmware-config.pl with CC environment variable pointing to the "gcc" version "2.96". Интересно, а почему не 3.3 ? Чем вызвано ? -- С уважением, Сергей a_s_y@sama.ru
[-- Attachment #1: Type: text/plain, Size: 490 bytes --] On Sat, Feb 14, 2004 at 01:16:57PM +0400, Sergey wrote: > Your kernel was built with "gcc" version "2.96", while you are trying to use [skip] > Интересно, а почему не 3.3 ? Чем вызвано ? Тогда был 3.2, и результаты тестирования производительности (неоднозначные по разным критериям) в сумме привели к решению собирать 2.4 2.96. Думаю, можно найти в архиве devel@ по "2.96 3.2.1 LTP rider". -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Hi! Подскажите, как у нас сейчас правильно собирать модули для ядра в отдельных пакетах? Вводная: Есть железяка Zyxel Prestige 630-11, которая поддерживается на альфа-уровне соответствующим проектом на sf.net. В его Makefile есть следующее: ifeq ($(PATCHLEVEL), 4) obj-y := $(xdslusb-module-objs) $(xdslusb-crc).o obj-m := $(XDSLUSB-MODULE).o O_TARGET := $(XDSLUSB-MODULE).o include $(TOPDIR)/Rules.make else obj-m := $(XDSLUSB-MODULE).o $(XDSLUSB-MODULE)-objs := $(xdslusb-module-objs) endif И отсылка на документацию: For kernel 2.6: http://lwn.net/Articles/21823/ For kernel 2.2 and 2.4: If you have a local makefile with which you wish to build your module not linked under the kernel tree in the proper way, you still can "ride" on the master Makefile. This way one can eliminate the dependency on your particular machine kernel compilation options to be hardwired in the local Makefile. I.e., once you reconfigure the kernel, your driver will compile itself when you do a local "make" with the correct set of the new flags. [...] Задача: собрать и опакетить этот модуль в существующем виде. Вопрос: как сейчас осуществляется сборка модулей _вне_ пакета с ядром? Буду благодарен покажут соответствующий пакет, который можно попользовать в качестве отправной точки. -- Andrey V Khavryuchenko http://www.kds.com.ua/ Silver Bullet Software Solutions http://www.kds.com.ua/training/
> Буду благодарен покажут соответствующий пакет, который можно попользовать в > качестве отправной точки. http://www.altlinux.ru/pipermail/devel-kernel/2003-July/002101.html И документация из kernel-build-tools, конечно. Кстати, потом оказалось, что ipsec_tunnel уже давно включён в ядро, так что единственная польза той диаграммы --- кому-то демонстрировать :) -- DO4-UANIC
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --] On Tue, Mar 16, 2004 at 04:09:27PM +0200, Andrey Khavryuchenko wrote: > Подскажите, как у нас сейчас правильно собирать модули для ядра в отдельных > пакетах? > > Вводная: > Есть железяка Zyxel Prestige 630-11, которая поддерживается на > альфа-уровне соответствующим проектом на sf.net. В его Makefile есть > следующее: > > ifeq ($(PATCHLEVEL), 4) > obj-y := $(xdslusb-module-objs) $(xdslusb-crc).o > obj-m := $(XDSLUSB-MODULE).o > O_TARGET := $(XDSLUSB-MODULE).o > include $(TOPDIR)/Rules.make > else > obj-m := $(XDSLUSB-MODULE).o > $(XDSLUSB-MODULE)-objs := $(xdslusb-module-objs) > endif Видимо, это должно собираться через Makefile ядра: make -C %_usrsrc/linux-%kversion-%flavour SUBDIRS=$(pwd) modules (это для 2.4.x) > Задача: собрать и опакетить этот модуль в существующем виде. > > Вопрос: как сейчас осуществляется сборка модулей _вне_ пакета с ядром? > > Буду благодарен покажут соответствующий пакет, который можно попользовать в > качестве отправной точки. kernel-modules-* (в каждом свои фокусы). [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Hi! Господа, в текущей системе сборки есть одна большая проблема: патчи мы в общем случай можем готовить только для одной версии ядра в пределах поколения, что приводит к тому, что практически невозможно работать с разными версиями ядер. Необходимость эта возникает как при переходе на новую версию, так, скажем, для сопровождения нескольких веток ядер (если std переходит на 2.4.25, то в тот же момент должны переходить и aw и что там еще есть). Есть предложение бороть эту проблему: 1) ядро будет запрашивать патчи строго своей версии (метка не 2.4, а, скажем, 2.4.x). Патчи разносить по каталогам для всех поддерживаемых версий. Так как одновременно будет поддерживаться не более 2-3 версий, избыточность будет не большая. 2) Править kernel-build-tools, чтобы в случае наличия общих патчей для ветки (2.4,скажем) прикладывались они, а так же патчи на конкретную версию. Требует бОльших усилий от ментейнера при добавлении версии (общая часть уже может перестать быть общей) -- Zhenja Kaluta ICQ 74596027 GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3 856E 7EE8 52DE E6B7 8725
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --] On Wed, Mar 17, 2004 at 01:08:22PM +0200, Zhenja Kaluta wrote: > Господа, в текущей системе сборки есть одна большая проблема: патчи мы > в общем случай можем готовить только для одной версии ядра в пределах > поколения, что приводит к тому, что практически невозможно работать с > разными версиями ядер. Необходимость эта возникает как при переходе на > новую версию, так, скажем, для сопровождения нескольких веток ядер > (если std переходит на 2.4.25, то в тот же момент должны переходить и > aw и что там еще есть). Есть предложение бороть эту проблему: > > 1) ядро будет запрашивать патчи строго своей версии (метка не 2.4, а, > скажем, 2.4.x). Патчи разносить по каталогам для всех поддерживаемых > версий. Так как одновременно будет поддерживаться не более 2-3 версий, > избыточность будет не большая. Причём эту избыточность можно попытаться побороть симлинками (только вот тут уже придётся вносить дополнения в kernel-build-tools, иначе будет неудобно). > 2) Править kernel-build-tools, чтобы в случае наличия общих патчей для > ветки (2.4,скажем) прикладывались они, а так же патчи на конкретную > версию. Требует бОльших усилий от ментейнера при добавлении версии > (общая часть уже может перестать быть общей) На самом деле там ничего не надо править - для каждого каталога условия проверяются независимо, да и вложенность работает. Например, сейчас в kernel-fix-security лежат рядом 00_not_kernel-fix-security-owl/ и 10_apply_to_2.4.22/, и нет никаких препятствий, чтобы положить туда ещё 20_2.6/. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
>>>>> "SV" == Sergey Vlasov writes:
SV> On Wed, Mar 17, 2004 at 01:08:22PM +0200, Zhenja Kaluta wrote:
>> Господа, в текущей системе сборки есть одна большая проблема: патчи мы
>> в общем случай можем готовить только для одной версии ядра в пределах
>> поколения, что приводит к тому, что практически невозможно работать с
>> разными версиями ядер. Необходимость эта возникает как при переходе на
>> новую версию, так, скажем, для сопровождения нескольких веток ядер
>> (если std переходит на 2.4.25, то в тот же момент должны переходить и
>> aw и что там еще есть). Есть предложение бороть эту проблему:
>>
>> 1) ядро будет запрашивать патчи строго своей версии (метка не 2.4, а,
>> скажем, 2.4.x). Патчи разносить по каталогам для всех поддерживаемых
>> версий. Так как одновременно будет поддерживаться не более 2-3 версий,
>> избыточность будет не большая.
SV> Причём эту избыточность можно попытаться побороть симлинками (только
SV> вот тут уже придётся вносить дополнения в kernel-build-tools, иначе
SV> будет неудобно).
>> 2) Править kernel-build-tools, чтобы в случае наличия общих патчей для
>> ветки (2.4,скажем) прикладывались они, а так же патчи на конкретную
>> версию. Требует бОльших усилий от ментейнера при добавлении версии
>> (общая часть уже может перестать быть общей)
SV> На самом деле там ничего не надо править - для каждого каталога
SV> условия проверяются независимо, да и вложенность работает.
SV> Например, сейчас в kernel-fix-security лежат рядом
SV> 00_not_kernel-fix-security-owl/ и 10_apply_to_2.4.22/, и нет никаких
SV> препятствий, чтобы положить туда ещё 20_2.6/.
всё отлично, всё прекрасно.
Как делать будем, чтобы разногласий не было?
--
Zhenja Kaluta ICQ 74596027
GnuPG FingerPrint: B86C B548 7CC4 B58F 0CA3 856E 7EE8 52DE E6B7 8725
On Wed, Mar 17, 2004 at 02:02:09PM +0200, Zhenja Kaluta wrote:
>
> >>>>> "SV" == Sergey Vlasov writes:
>
> SV> On Wed, Mar 17, 2004 at 01:08:22PM +0200, Zhenja Kaluta wrote:
> >> Господа, в текущей системе сборки есть одна большая проблема: патчи мы
> >> в общем случай можем готовить только для одной версии ядра в пределах
> >> поколения, что приводит к тому, что практически невозможно работать с
> >> разными версиями ядер. Необходимость эта возникает как при переходе на
> >> новую версию, так, скажем, для сопровождения нескольких веток ядер
> >> (если std переходит на 2.4.25, то в тот же момент должны переходить и
> >> aw и что там еще есть). Есть предложение бороть эту проблему:
> >>
> >> 1) ядро будет запрашивать патчи строго своей версии (метка не 2.4, а,
> >> скажем, 2.4.x). Патчи разносить по каталогам для всех поддерживаемых
> >> версий. Так как одновременно будет поддерживаться не более 2-3 версий,
> >> избыточность будет не большая.
>
> SV> Причём эту избыточность можно попытаться побороть симлинками (только
> SV> вот тут уже придётся вносить дополнения в kernel-build-tools, иначе
> SV> будет неудобно).
>
> >> 2) Править kernel-build-tools, чтобы в случае наличия общих патчей для
> >> ветки (2.4,скажем) прикладывались они, а так же патчи на конкретную
> >> версию. Требует бОльших усилий от ментейнера при добавлении версии
> >> (общая часть уже может перестать быть общей)
>
> SV> На самом деле там ничего не надо править - для каждого каталога
> SV> условия проверяются независимо, да и вложенность работает.
> SV> Например, сейчас в kernel-fix-security лежат рядом
> SV> 00_not_kernel-fix-security-owl/ и 10_apply_to_2.4.22/, и нет никаких
> SV> препятствий, чтобы положить туда ещё 20_2.6/.
>
> всё отлично, всё прекрасно.
>
> Как делать будем, чтобы разногласий не было?
IMHO так, как прописано в policy.
On Tuesday 16 March 2004 17:09, Andrey Khavryuchenko wrote: > Hi! > > Подскажите, как у нас сейчас правильно собирать модули для > ядра в отдельных пакетах? > > Вводная: > Есть железяка Zyxel Prestige 630-11, которая поддерживается на > альфа-уровне соответствующим проектом на sf.net. В его > Makefile есть следующее: ... > Задача: собрать и опакетить этот модуль в существующем виде. Пожалуйста, держите меня в курсе, потому что я тоже собираю поддержку этого ADSL-модема. Кстати, вы уже собрали плагин pppoatm для ppp? Модуль ядра-то без проблем собирается... -- Lav Виталий Липатов Санкт-Петербург GNU! ALT Linux Team! LaTeX! LyX!
Приветствую! Подскажите, как можно посмотреть список доступных значений, которые принимает модуль в качестве параметра при загрузке (card=ХХХ для модуля saa7134). Информация на сайте http://bytesex.org/saa7134 содержит почти в два раза меньше карт, чем поддерживал модуль для ядра (2.4.22-alt12). Так например моя карта Manli присутствовала в списке под номером 27, а на сате написано о поддержке только 15-ти карт. -- У каждого в башке свои тараканы...
[-- Attachment #1: Type: text/plain, Size: 767 bytes --] On Thu, Apr 01, 2004 at 12:11:40PM +0400, Genix wrote: > Подскажите, как можно посмотреть список доступных значений, которые > принимает модуль в качестве параметра при загрузке (card=ХХХ для модуля > saa7134). /usr/share/doc/kernel-modules-v4l-*/saa7134/CARDLIST > Информация на сайте http://bytesex.org/saa7134 содержит почти в два раза > меньше карт, чем поддерживал модуль для ядра (2.4.22-alt12). Так > например моя карта Manli присутствовала в списке под номером 27, а на > сате написано о поддержке только 15-ти карт. Всё-таки 17, а не 27. Сайты часто обновляются с задержкой, а поддержка карт Manli так и вообще добавлена местным патчем. Кстати, с этой картой всё нормально работает, и как она точно называется? Надо бы этот патч в upstream запихать... [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
On Thu, 1 Apr 2004 13:54:24 +0400 Sergey Vlasov <vsu@altlinux.ru> wrote: > > Информация на сайте http://bytesex.org/saa7134 содержит почти в два > > раза меньше карт, чем поддерживал модуль для ядра (2.4.22-alt12). > > Так например моя карта Manli присутствовала в списке под номером 27, > > а на сате написано о поддержке только 15-ти карт. > > Всё-таки 17, а не 27. Сайты часто обновляются с задержкой, а > поддержка карт Manli так и вообще добавлена местным патчем. Странно, в modules.conf для нее задано значение 27... И если мне не изменяет склероз, именно это значение было рекомендовано в /var/log/messages при первой загрузке модуля... > Кстати, с этой картой всё нормально работает, и как она точно > называется? Надо бы этот патч в upstream запихать... Да, модуль заработал, но только не работал режим mute для звука (многие владельцы карт на этом чипсете жаловались, не только Manli) а радио не пробовал (за ненадобностью). На сайте http://www.manli.ru/m_tv002.html она названа как M-TV002 (версия с радио), хотя в документации которая шла с ней на диске она называлась Manli Much TV Plus (возможно эти два названия и не противоречат друг другу). -- У каждого в башке свои тараканы...
[-- Attachment #1: Type: text/plain, Size: 60 bytes --] Ничего плохого не делал... ядро 2.4.26-alt2 Оппс приложен. [-- Attachment #2: 222 --] [-- Type: application/octet-stream, Size: 1958 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1292 bytes --] On Mon, Jun 07, 2004 at 11:58:31AM +0400, Александр Новосёлов wrote: > Ничего плохого не делал... Делали - см. ниже. > ядро 2.4.26-alt2 А точнее (std/wks, up/smp)? > Jun 6 18:30:45 admin pam_tcb[2104]: kde: Session closed for nai > Jun 6 18:30:45 admin kernel: [drm] Loading R200 Microcode > Jun 6 18:30:47 admin kernel: Unable to handle kernel paging request at virtual address 00ad0c88 > Jun 6 18:30:47 admin kernel: printing eip: > Jun 6 18:30:47 admin kernel: c012ada7 > Jun 6 18:30:47 admin kernel: *pde = 00000000 > Jun 6 18:30:47 admin kernel: Oops: 0000 > Jun 6 18:30:47 admin kernel: CPU: 0 > Jun 6 18:30:47 admin kernel: EIP: 1010:[filemap_fdatawait+39/192] Tainted: PF Tainted: P - загрузка модуля с лицензией, несовместимой с GPL (т.е., как правило, без исходников). Tainted: F - загрузка модуля с опцией --force (собранного не для этого ядра и, следовательно, потенциально несовместимого по интерфейсам). > Jun 6 18:30:47 admin kernel: Call Trace: [sync_unlocked_inodes+236/448] [process_timeout+0/80] [sync_old_buffers+5/80] [kupdate+276/336] [mki_ret_user+13/16] mki_ret_user - насколько я помню, Win4Lin. Постарайтесь воспроизвести эту проблему без него - никто, кроме его разработчиков, не знает, что происходит в недрах его бинарных модулей. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
On Mon, 7 Jun 2004 13:14:08 +0400 Sergey Vlasov <vsu@altlinux.ru> wrote: > Tainted: P - загрузка модуля с лицензией, несовместимой с GPL > (т.е., как правило, без исходников). > > Tainted: F - загрузка модуля с опцией --force (собранного не > для этого ядра и, следовательно, потенциально несовместимого по > интерфейсам). Оп, кстати да... Было загружено ядро, с mki патчами... Это я его для конторы компилил, да видимо задефолтил. т.е. на моей машине win4lin сейчас не используется! Хотя rpm установлен. И что характерно... у них все работает :) Как мне казалось модули ядра у win4lin как раз открытые. Закрытые модули в данный момент не используются т.е вместо fglrx родной иксовый драйвер. Еще, загружены модули Vmware. А где можно про отладочные сообщения почитать (Tainted:) Тут надо разобраться кто куролесит в моей машине, кроме меня :) > > Jun 6 18:30:47 admin kernel: Call Trace: > > [sync_unlocked_inodes+236/448] [process_timeout+0/80] > > [sync_old_buffers+5/80] [kupdate+276/336] > > [mki_ret_user+13/16] > > mki_ret_user - насколько я помню, Win4Lin. > > Постарайтесь воспроизвести эту проблему без него - никто, кроме > его разработчиков, не знает, что происходит в недрах его > бинарных модулей. ok, приду домой перегружу, но... это похоже из серии подземных стуков. С момента установки и посейчас падало только 1 раз.
[-- Attachment #1: Type: text/plain, Size: 538 bytes --] On Mon, Jun 07, 2004 at 02:19:02PM +0400, Александр Новосёлов wrote: > Еще, загружены модули Vmware. Maybe из-за них и Tainted. Они хоть и с исходниками, но без лицензии. У меня: vmmon: module license 'unspecified' taints kernel. А вот F все-таки откуда? >А где можно про отладочные сообщения почитать (Tainted:) oops-tracing.txt из kernel-doc. -- WBR, wRAR (ALT Linux Team) modutils вполне работоспособен... лично мне он в нынешнем виде нравится.. а вот что скажет на эту тему ldv ??? -- rider in devel-kernel@ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Здравствуйте! Вообщем вот. Новость #4062 Дата: 14.06.2004 Тема: Опасная уязвимость в Linux-ядрах 2.4.x, 2.6.x Автор: SHuRuP (http://www.nixp.ru/shurup/) Содержание: Ошибка в math_error() позволяет произвести DoS. Нужно всего лишь вызвать FPU exception в обработчике сигнала. Подвержены Linux-ядра 2.4.x, 2.6.x. Эксплоит и инструкции по устранению ошибки доступны на homelinux.org [http://reviewed.homelinux.org/news/2004-06-11_kernel_crash/index.html.en]. Обсуждения на lkml.org >> [http://lkml.org/lkml/2004/6/12/23] (Новость прислал: slavik [to_trash[аt]mail.ru].) Источник: http://linux.org.ru
[-- Attachment #1: Type: text/plain, Size: 271 bytes --] А как у нас обстоят дела с пересборкой ядра в Сизифе. Ситуация такая - я обновил патч, от которого зависело ядро. Надо ли повышать релиз у ядра и закачивать его снова, или оно и так будет пересобрано с новым патчем? IMHO надо повышать релиз, ибо ядра получатся разные. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Так я и не понял, какие действия нужно предпринять для сборки пакетов с модулями ядра? Я выложил в Incoming kernel-source-amedyn-2003.10.29-2003.10.29-alt3.src.rpm kernel-modules-amedyn-std-up-2003.10.29-alt2.src.rpm Этого достаточно? P.S. Выкладывание согласовано с мантейтером пакетов Andrey V Khavryuchenko <akhavr@altlinux.org> -- Lav Виталий Липатов Санкт-Петербург GNU! ALT Linux Team! LaTeX! LyX!
Vitaly Lipatov пишет:
> Так я и не понял, какие действия нужно предпринять для сборки
> пакетов с модулями ядра?
> Я выложил в Incoming
> kernel-source-amedyn-2003.10.29-2003.10.29-alt3.src.rpm
> kernel-modules-amedyn-std-up-2003.10.29-alt2.src.rpm
> Этого достаточно?
> P.S. Выкладывание согласовано с мантейтером пакетов
> Andrey V Khavryuchenko <akhavr@altlinux.org>
>
Нужно также сбрасывать изменения в CVS, что бы в дальнейшем этот модуль
пересобирался для всех остальных ядер.
Rgds,
Rider
On Mon, Jul 12, 2004 at 10:49:35AM +0400, Anton Farygin wrote: > >Так я и не понял, какие действия нужно предпринять для сборки > >пакетов с модулями ядра? > Нужно также сбрасывать изменения в CVS, что бы в дальнейшем > этот модуль пересобирался для всех остальных ядер. А... (застенчиво) можно я попробую "вдогонку" собрать kernel-{source,modules}-apanel? ;-) С ним Fujitsu Lifebook работает еще более на полную... (а то как же это ж мы подымем его менее, чем gentoo или freebsd? ;-) -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
On Monday 12 July 2004 10:49, Anton Farygin wrote:
> Нужно также сбрасывать изменения в CVS, что бы в дальнейшем
> этот модуль пересобирался для всех остальных ядер.
Как я могу сбросить его в CVS, если я не в kernel-team?
--
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!
Vitaly Lipatov пишет:
> On Monday 12 July 2004 10:49, Anton Farygin wrote:
>
>>Нужно также сбрасывать изменения в CVS, что бы в дальнейшем
>>этот модуль пересобирался для всех остальных ядер.
>
> Как я могу сбросить его в CVS, если я не в kernel-team?
>
Действительно ;-)
Хотя, я все-таки считаю, что каждый собирающий что-то для ядра или около
ядра - автоматом попадает в kernel team.
Rgds,
Rider
Здравствуйте. Хочу прояснить порядок работы с пакетами относящимися к ядру. Желаю выложить ядро kernel-image-rt[26]-{up,smp}. Нужно добавить kernel-feat-core-adeos, kernel-modules-rtai и kernel-image-rt-[26]-{up,smp} в Kernel CVS, а также kernel-source-rtai в Сизиф. С чего начинать? %description -n kernel-feat-core-adeos Adeos nanokernel. Instead of first building the nanokernel and then building the client OSes, Adeos started from a live and known-to-be-functional OS, Linux, and inserted a nanokernel beneath it. Starting from Adeos, other client OSes can now be put side-by-side with the Linux kernel. %description -n kernel-modules-rtai This package contains the RTAI (Real-Time Application Interface) system and is intended for developers who are building embedded systems that will run the Linux operating system. In fact, RTAI is based on the Linux operating system to which it adds real-time capabilities that are not natively supported since Linux is a user-oriented operating system. Sin
On Mon, Sep 20, 2004 at 11:46:00PM +0400, Evgeny Sinelnikov wrote:
> Здравствуйте.
> Хочу прояснить порядок работы с пакетами относящимися к ядру. Желаю выложить
> ядро kernel-image-rt[26]-{up,smp}. Нужно добавить kernel-feat-core-adeos,
> kernel-modules-rtai и kernel-image-rt-[26]-{up,smp} в Kernel CVS, а также
> kernel-source-rtai в Сизиф. С чего начинать?
>
> 0escription -n kernel-feat-core-adeos
> Adeos nanokernel. Instead of first building the nanokernel and then
> building the client OSes, Adeos started from a live and
> known-to-be-functional OS, Linux, and inserted a nanokernel beneath it.
> Starting from Adeos, other client OSes can now be put side-by-side with the
> Linux kernel.
>
> 0escription -n kernel-modules-rtai
> This package contains the RTAI (Real-Time Application Interface)
> system and is intended for developers who are building embedded
> systems that will run the Linux operating system. In fact, RTAI
> is based on the Linux operating system to which it adds real-time
> capabilities that are not natively supported since Linux is a
> user-oriented operating system.
>
Ура! Наконец-то оно появится в Сизифе (может лучше в Дедалус для
начала?). Огромное спасибо за работу по подготовке ядра!
Может лучше ядро назвать rtai26, а не rt26? Вроде бы так
понятнее...
--
Юрий А. Зотов
В сообщении от 21 Сентябрь 2004 01:05 Yura Zotov написал(a): > On Mon, Sep 20, 2004 at 11:46:00PM +0400, Evgeny Sinelnikov wrote: > > Здравствуйте. > > Хочу прояснить порядок работы с пакетами относящимися к ядру. Желаю > > выложить ядро kernel-image-rt[26]-{up,smp}. Нужно добавить > > kernel-feat-core-adeos, kernel-modules-rtai и > > kernel-image-rt-[26]-{up,smp} в Kernel CVS, а также kernel-source-rtai в > > Сизиф. С чего начинать? > > > > 0escription -n kernel-feat-core-adeos > > Adeos nanokernel. Instead of first building the nanokernel and then > > building the client OSes, Adeos started from a live and > > known-to-be-functional OS, Linux, and inserted a nanokernel beneath it. > > Starting from Adeos, other client OSes can now be put side-by-side with > > the Linux kernel. > > > > 0escription -n kernel-modules-rtai > > This package contains the RTAI (Real-Time Application Interface) > > system and is intended for developers who are building embedded > > systems that will run the Linux operating system. In fact, RTAI > > is based on the Linux operating system to which it adds real-time > > capabilities that are not natively supported since Linux is a > > user-oriented operating system. > > Ура! Наконец-то оно появится в Сизифе (может лучше в Дедалус для > начала?). Огромное спасибо за работу по подготовке ядра! > То есть, можно все просто положить в Deadalus? Хм... Да, тогда Kernel CVS, видимо пока не понадобться, если сборки ядер из cvs идут только Сизиф. А было бы удобно... > Может лучше ядро назвать rtai26, а не rt26? Вроде бы так > понятнее... > Я думаю, что rt26 лучше. Дело вот в чем. Изменения ядра минимальны и позволяют использовать не только модули RTAI. По некоторым заявлениям в списках рассылки будущие версии, несколько отставшего, RTLinux для ветки 2.6 предполагаются тоже основывать на ядрах запущенных поверх Adeos. Sin
On Tue, Sep 21, 2004 at 10:44:58AM +0400, Evgeny Sinelnikov wrote: > В сообщении от 21 Сентябрь 2004 01:05 Yura Zotov написал(a): > > On Mon, Sep 20, 2004 at 11:46:00PM +0400, Evgeny Sinelnikov wrote: > > > Здравствуйте. > > > Хочу прояснить порядок работы с пакетами относящимися к ядру. Желаю > > > выложить ядро kernel-image-rt[26]-{up,smp}. Нужно добавить > > > kernel-feat-core-adeos, kernel-modules-rtai и > > > kernel-image-rt-[26]-{up,smp} в Kernel CVS, а также kernel-source-rtai в > > > Сизиф. С чего начинать? > > > > > > 0escription -n kernel-feat-core-adeos > > > Adeos nanokernel. Instead of first building the nanokernel and then > > > building the client OSes, Adeos started from a live and > > > known-to-be-functional OS, Linux, and inserted a nanokernel beneath it. > > > Starting from Adeos, other client OSes can now be put side-by-side with > > > the Linux kernel. > > > > > > 0escription -n kernel-modules-rtai > > > This package contains the RTAI (Real-Time Application Interface) > > > system and is intended for developers who are building embedded > > > systems that will run the Linux operating system. In fact, RTAI > > > is based on the Linux operating system to which it adds real-time > > > capabilities that are not natively supported since Linux is a > > > user-oriented operating system. > > > > Ура! Наконец-то оно появится в Сизифе (может лучше в Дедалус для > > начала?). Огромное спасибо за работу по подготовке ядра! > > > > То есть, можно все просто положить в Deadalus? > Хм... Да, тогда Kernel CVS, видимо пока не понадобться, если сборки ядер из > cvs идут только Сизиф. А было бы удобно... > Про порядок выкладывания ядер я мало что знаю. Про Дедалус сказал, потому что думал так будет лучше, так как это ядро может быть нестабильным. > > Может лучше ядро назвать rtai26, а не rt26? Вроде бы так > > понятнее... > > > > Я думаю, что rt26 лучше. Дело вот в чем. Изменения ядра минимальны и позволяют > использовать не только модули RTAI. По некоторым заявлениям в списках > рассылки будущие версии, несколько отставшего, RTLinux для ветки 2.6 > предполагаются тоже основывать на ядрах запущенных поверх Adeos. > А! Вот в чём дело. Т.е. на том же самом ядре можно будет запустить ещё и rtl? А одновременно rtai и rtl можно? :-) В таком случае, может тогда назвать ядро adeos26? Мало ли появятся какие-то системы, использующие adeos, но не rt. -- Юрий А. Зотов
On Tue, 21 Sep 2004 15:29:58 +0400
Yura Zotov <yz@altlinux.ru> wrote:
> А! Вот в чём дело. Т.е. на том же самом ядре можно будет
> запустить ещё и rtl? А одновременно rtai и rtl можно? :-)
>
> В таком случае, может тогда назвать ядро adeos26? Мало ли
> появятся какие-то системы, использующие adeos, но не rt.
rt -- аббревиатура которая на слуху у многих, adeos только у избранных.
--
У каждого в башке свои тараканы...
Genix <genix@list.ru> writes:
> On Tue, 21 Sep 2004 15:29:58 +0400
> Yura Zotov <yz@altlinux.ru> wrote:
>
>> А! Вот в чём дело. Т.е. на том же самом ядре можно будет
>> запустить ещё и rtl? А одновременно rtai и rtl можно? :-)
>>
>> В таком случае, может тогда назвать ядро adeos26? Мало ли
>> появятся какие-то системы, использующие adeos, но не rt.
>
> rt -- аббревиатура которая на слуху у многих, adeos только у избранных.
Ну так посмотрит человек на непонятную аббревиатуру, прочитает что это
такое, почитает документацию и станет избранным ;)
--
With Best Regards, Maxim Tyurin aka Bungarus
JID: MrKooll@jabber.pibhe.com
В сообщении от 21 Сентябрь 2004 15:29 Yura Zotov написал(a): > On Tue, Sep 21, 2004 at 10:44:58AM +0400, Evgeny Sinelnikov wrote: > > В сообщении от 21 Сентябрь 2004 01:05 Yura Zotov написал(a): > > > On Mon, Sep 20, 2004 at 11:46:00PM +0400, Evgeny Sinelnikov wrote: > > > > Здравствуйте. > > > > Хочу прояснить порядок работы с пакетами относящимися к ядру. Желаю > > > > выложить ядро kernel-image-rt[26]-{up,smp}. Нужно добавить > > > > kernel-feat-core-adeos, kernel-modules-rtai и > > > > kernel-image-rt-[26]-{up,smp} в Kernel CVS, а также > > > > kernel-source-rtai в Сизиф. С чего начинать? > > > > > > > > %description -n kernel-feat-core-adeos > > > > Adeos nanokernel. Instead of first building the nanokernel and then > > > > building the client OSes, Adeos started from a live and > > > > known-to-be-functional OS, Linux, and inserted a nanokernel beneath > > > > it. Starting from Adeos, other client OSes can now be put > > > > side-by-side with the Linux kernel. > > > > > > > > %description -n kernel-modules-rtai > > > > This package contains the RTAI (Real-Time Application Interface) > > > > system and is intended for developers who are building embedded > > > > systems that will run the Linux operating system. In fact, RTAI > > > > is based on the Linux operating system to which it adds real-time > > > > capabilities that are not natively supported since Linux is a > > > > user-oriented operating system. > > > > > > Ура! Наконец-то оно появится в Сизифе (может лучше в Дедалус для > > > начала?). Огромное спасибо за работу по подготовке ядра! > > > > То есть, можно все просто положить в Deadalus? > > Хм... Да, тогда Kernel CVS, видимо пока не понадобться, если сборки ядер > > из cvs идут только Сизиф. А было бы удобно... > > Про порядок выкладывания ядер я мало что знаю. Про Дедалус > сказал, потому что думал так будет лучше, так как это ядро > может быть нестабильным. > Да, я согласен, что нужно тестировать. К сожалению, моих мощностей хватило только на тестовую машину для *-up ядер. Как будет себя вести smp даже не знаю. Есть вопросы по размещению библиотек, собираемых под каждое ядро, в виду тесной связи по включаемым файлам и конкретной конфигурации. Исходная устанока проводится в каталог /usr/realtime, где аккуратно сложены: ./bin ./lib ./share ./include ./testsuite ./calibration Первое, что приходит на ум, это переместить установку в каталог /usr/lib/kernel/realtime-%version-%flavor и поручить скриптам поправлять ссылку на /usr/realtime. Если нет возражений так и оставлю. В добавлении ко всему был ещё [./modules], но я его убрал в, /lib/modules/%kversion-%flavour-%krelease/%module_name И кстати, чтобы скрипты из ./bin заработали небходим доступ пользователя в каталог /lib/modules, поскольку в них используется рекурсивно запускаемый sudo insmod, вместо sudo modprobe. Может их лучше оставить там же и ввести группу? > > > Может лучше ядро назвать rtai26, а не rt26? Вроде бы так > > > понятнее... > > > > Я думаю, что rt26 лучше. Дело вот в чем. Изменения ядра минимальны и > > позволяют использовать не только модули RTAI. По некоторым заявлениям в > > списках рассылки будущие версии, несколько отставшего, RTLinux для ветки > > 2.6 предполагаются тоже основывать на ядрах запущенных поверх Adeos. > > А! Вот в чём дело. Т.е. на том же самом ядре можно будет > запустить ещё и rtl? А одновременно rtai и rtl можно? :-) Если поместить их в разные домены то, может быть что-то и получится, но кто-то из них, тогда точно перестанет работать в реальном времени - попадёт в виртуальное :) > В таком случае, может тогда назвать ядро adeos26? Мало ли > появятся какие-то системы, использующие adeos, но не rt. Выглядит пугающе :) rt мне больше нравится, мы же называем ядра по способу использования, а не по именам накладываемых патчей. Sin
On Wed, Sep 22, 2004 at 01:14:02AM +0400, Evgeny Sinelnikov wrote: > > Про порядок выкладывания ядер я мало что знаю. Про Дедалус > > сказал, потому что думал так будет лучше, так как это ядро > > может быть нестабильным. > > > > Да, я согласен, что нужно тестировать. К сожалению, моих мощностей хватило > только на тестовую машину для *-up ядер. Как будет себя вести smp даже не > знаю. Есть вопросы по размещению библиотек, собираемых под каждое ядро, в > виду тесной связи по включаемым файлам и конкретной конфигурации. > Исходная устанока проводится в каталог /usr/realtime, где аккуратно сложены: > ./bin > ./lib > ./share > ./include > ./testsuite > ./calibration > > Первое, что приходит на ум, это переместить установку в > каталог /usr/lib/kernel/realtime-%version-%flavor и поручить скриптам > поправлять ссылку на /usr/realtime. Если нет возражений так и оставлю. /usr/realtime быть не может (противоречит FHS), так что ищите другое место (например, /etc/sysconfig/kernel/realtime -- там уже есть симлинк для include). -- / Alexander Bokovoy Samba Team http://www.samba.org/ ALT Linux Team http://www.altlinux.org/ Midgard Project Ry http://www.midgard-project.org/
В сообщении от 22 Сентябрь 2004 13:18 Alexander Bokovoy написал(a):
> On Wed, Sep 22, 2004 at 01:14:02AM +0400, Evgeny Sinelnikov wrote:
> > > Про порядок выкладывания ядер я мало что знаю. Про Дедалус
> > > сказал, потому что думал так будет лучше, так как это ядро
> > > может быть нестабильным.
> >
> > Да, я согласен, что нужно тестировать. К сожалению, моих мощностей
> > хватило только на тестовую машину для *-up ядер. Как будет себя вести smp
> > даже не знаю. Есть вопросы по размещению библиотек, собираемых под каждое
> > ядро, в виду тесной связи по включаемым файлам и конкретной конфигурации.
> > Исходная устанока проводится в каталог /usr/realtime, где аккуратно
> > сложены: ./bin
> > ./lib
> > ./share
> > ./include
> > ./testsuite
> > ./calibration
> >
> > Первое, что приходит на ум, это переместить установку в
> > каталог /usr/lib/kernel/realtime-%version-%flavor и поручить скриптам
> > поправлять ссылку на /usr/realtime. Если нет возражений так и оставлю.
>
> /usr/realtime быть не может (противоречит FHS), так что ищите другое место
> (например, /etc/sysconfig/kernel/realtime -- там уже есть симлинк для
> include).
Так, тогда предлагаю такой вариант.
структуры каталогов укладывать в /usr/lib/kernel/realtime-%version-%flavor, а
ссылку, на это хозяйтсво перевести из /usr/realtime в /opt/realtime. Это
подходит в рамки FHS? Ну, а /etc/sysconfig/kernel/realtime -- по аналогии с
include, ссылается на нужную директорию adjust скриптом, при
этом /opt/realtime, опять же по аналогии, всегда ссылается
на /etc/sysconfig/kernel/realtime. Вобщем написание пакета,
kernel-realtime-common беру на себя. Насколько я понял, здесь сразу можно
запользовать alternatives.
Sin
On Thu, Sep 23, 2004 at 12:59:24AM +0400, Evgeny Sinelnikov wrote: > > /usr/realtime быть не может (противоречит FHS), так что ищите другое место > > (например, /etc/sysconfig/kernel/realtime -- там уже есть симлинк для > > include). > > Так, тогда предлагаю такой вариант. > структуры каталогов укладывать в /usr/lib/kernel/realtime-%version-%flavor, а > ссылку, на это хозяйтсво перевести из /usr/realtime в /opt/realtime. Это > подходит в рамки FHS? Ну, а /etc/sysconfig/kernel/realtime -- по аналогии с > include, ссылается на нужную директорию adjust скриптом, при > этом /opt/realtime, опять же по аналогии, всегда ссылается > на /etc/sysconfig/kernel/realtime. Вобщем написание пакета, > kernel-realtime-common беру на себя. Насколько я понял, здесь сразу можно > запользовать alternatives. Дело в том, что в /opt и /usr/local пакеты из дистрибутива ставиться не должны, туда попадает коммерческое ПО третьей стороны (первое) и локальные системные изменения (второе). -- / Alexander Bokovoy Samba Team http://www.samba.org/ ALT Linux Team http://www.altlinux.org/ Midgard Project Ry http://www.midgard-project.org/
В сообщении от 23 Сентябрь 2004 13:22 Alexander Bokovoy написал(a):
> On Thu, Sep 23, 2004 at 12:59:24AM +0400, Evgeny Sinelnikov wrote:
> > > /usr/realtime быть не может (противоречит FHS), так что ищите другое
> > > место (например, /etc/sysconfig/kernel/realtime -- там уже есть
> > > симлинк для include).
> >
> > Так, тогда предлагаю такой вариант.
> > структуры каталогов укладывать в
> > /usr/lib/kernel/realtime-%version-%flavor, а ссылку, на это хозяйтсво
> > перевести из /usr/realtime в /opt/realtime. Это подходит в рамки FHS? Ну,
> > а /etc/sysconfig/kernel/realtime -- по аналогии с include, ссылается на
> > нужную директорию adjust скриптом, при
> > этом /opt/realtime, опять же по аналогии, всегда ссылается
> > на /etc/sysconfig/kernel/realtime. Вобщем написание пакета,
> > kernel-realtime-common беру на себя. Насколько я понял, здесь сразу можно
> > запользовать alternatives.
>
> Дело в том, что в /opt и /usr/local пакеты из дистрибутива ставиться не
> должны, туда попадает коммерческое ПО третьей стороны (первое) и локальные
> системные изменения (второе).
Есть еще вариант, раставить линки на файлы разделяемых библиотек и включаемых
файлов и скриптов. Но при этом возникает вопрос. А куда девать testsuite?
Вобщем получаем такую схему:
/bin/rtai-* ссылаются на настоящие скрипты
/usr/lib/kernel/realtime-%version-%flavor/bin;
/usr/include/rtai-* - в /usr/lib/kernel/realtime-%version-%flavor/include;
/usr/lib/liblxrt.so* /usr/lib/kernel/realtime-%version-%flavor/lib;
...
В итоге, лучше поставить один пакет rtai для текущего rt ядра и только одного.
Сложность в том, что такой пакет будет различатся даже для ядер одной версии
smp и up, впрочем как все РТ приложения. Есть еще варианты? Какой
предпочтительней?
Sin
Господа! В связи с появлением новой версии ядра (2.4.27), и необходимостью опакетить некоторые сторонние модули, хочу спросить - какова процедура размещения пакета в пресловутом CVS, чтобы он автоматом пересобирался с каждой сборкой ядра? Есть где-нибудь инструкция? Что делать-то надо? -- Lav Виталий Липатов Санкт-Петербург GNU! ALT Linux Team! LaTeX! LyX!
[-- Attachment #1: Type: text/plain, Size: 730 bytes --] On Wed, Oct 20, 2004 at 11:35:16PM +0400, Vitaly Lipatov wrote: > и необходимостью опакетить некоторые сторонние модули, Какие, если не секрет? > хочу спросить - какова процедура размещения пакета в пресловутом > CVS, чтобы он автоматом пересобирался с каждой сборкой ядра? Для 2.4, я так понимаю, автоматом, для 2.6 надо править image/%flavour/modules.build. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): Чего например не хватает лично мне, то это службы прогноза - некого "Сизиф-метео". Типа "по состоянию на 0.00 такого-то дня стабильность Сизифа N%, unmets M%, ldv собрал новый rpm - в течение трех суток ожидается усиление нестабильности, вплоть до ураганной". -- jaa in sisyphus@ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Vitaly Lipatov пишет:
> Господа!
> В связи с появлением новой версии ядра (2.4.27),
> и необходимостью опакетить некоторые сторонние модули,
> хочу спросить - какова процедура размещения пакета в пресловутом
> CVS, чтобы он автоматом пересобирался с каждой сборкой ядра?
> Есть где-нибудь инструкция? Что делать-то надо?
>
Все тривиально:
1) скачать CVS
2) прочитать README
3) выполнить
4) закоммитить
Rgds,
Rider
P.S.
А что собственно это за модули ?
On Thursday 21 October 2004 07:28, Andrey Rahmatullin wrote:
> On Wed, Oct 20, 2004 at 11:35:16PM +0400, Vitaly Lipatov wrote:
> > и необходимостью опакетить некоторые сторонние модули,
>
> Какие, если не секрет?
Например, amedyn - поддержка USB ADSL модема.
--
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!
On Thursday 21 October 2004 09:55, Anton Farygin wrote: > Все тривиально: > > 1) скачать CVS Не получается. А есть где прочитать как, кроме архива рассылки? $ cvs -d anoncvs@anoncvs.altlinux.org:/cvs/kernel co kernel can't create temporary directory /tmp/cvs-serv10704 > 2) прочитать README > 3) выполнить > 4) закоммитить > А что собственно это за модули ? kernel-modules-amedyn -- Lav Виталий Липатов Санкт-Петербург GNU! ALT Linux Team! LaTeX! LyX!
[-- Attachment #1: Type: text/plain, Size: 435 bytes --] On Wed, Oct 27, 2004 at 12:34:43AM +0400, Vitaly Lipatov wrote: > On Thursday 21 October 2004 09:55, Anton Farygin wrote: > > > Все тривиально: > > > > 1) скачать CVS > Не получается. А есть где прочитать как, кроме архива рассылки? > $ cvs -d anoncvs@anoncvs.altlinux.org:/cvs/kernel co kernel > can't create temporary directory /tmp/cvs-serv10704 Это я сломал всего несколько часов назад. Уже исправлено. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 348 bytes --] Добрый вечер. Машинка с ALM 2.4. Запустил в консоли сборку LTSP. Через 10-15 минут в логи посыпались сообщения об ошибках (файл err.log). Ещё через пол-минуты компьютер подвис. По совету Мишы Шигорина отключил сервис splash -- помогло. Вопрос следующий -- на кого вешать багу? На splash или на поддержку fb в ядре? -- WBR, Alexander Kuprin [-- Attachment #2: err.log --] [-- Type: text/x-log, Size: 2057 bytes --] Nov 30 12:06:13 lts kernel: Error 13 while decompressing splash screen. Nov 30 12:06:13 lts kernel: Unable to handle kernel paging request at virtual address f8ca4000 Nov 30 12:06:13 lts kernel: printing eip: Nov 30 12:06:13 lts kernel: c01ef2a3 Nov 30 12:06:13 lts kernel: *pde = 00000001 Nov 30 12:06:13 lts kernel: *pte = 00000000 Nov 30 12:06:13 lts kernel: Oops: 0002 Nov 30 12:06:13 lts kernel: CPU: 1 Nov 30 12:06:13 lts kernel: EIP: 0010:[col221111_16+275/912] Not tainted Nov 30 12:06:13 lts kernel: EIP: 0010:[<c01ef2a3>] Not tainted Nov 30 12:06:13 lts kernel: EFLAGS: 00010202 Nov 30 12:06:13 lts kernel: eax: 000062ec ebx: 000062ec ecx: 000062e0 edx: f8ca4000 Nov 30 12:06:13 lts kernel: esi: 00000000 edi: 00000003 ebp: 00000001 esp: f7eebe4c Nov 30 12:06:13 lts kernel: ds: 0018 es: 0018 ss: 0018 Nov 30 12:06:13 lts kernel: Process keventd (pid: 2, stackpage=f7eeb000) Nov 30 12:06:13 lts kernel: Stack: fffffffd f8c8aa40 f8c8a640 f8ca4800 f8ca4000 00000004 00000002 f8c8a640 Nov 30 12:06:13 lts kernel: 00000040 f8c8ac40 f8cb0000 c01ee108 f8c8a640 f8ca4000 00000800 00000000 Nov 30 12:06:13 lts kernel: 00000064 f8ca4000 00000003 00000000 00000030 00000006 00000003 00000023 Nov 30 12:06:13 lts kernel: Call Trace: [jpeg_decode+1384/1488] [splash_prepare+727/976] [fbcon_switch+53/480] [redraw_screen+215/336] [complete_change_console+40/192] Nov 30 12:06:13 lts kernel: Call Trace: [<c01ee108>] [<c01ebc67>] [<c01e4d85>] [<c01a6937>] [<c01a40c8>] Nov 30 12:06:13 lts kernel: [__console_callback+52/176] [console_callback+10/16] [__run_task_queue+93/112] [context_thread+325/496] [context_thread+0/496] [rest_init+0/80] Nov 30 12:06:13 lts kernel: [<c01a9b94>] [<c01a9b5a>] [<c01230ed>] [<c012be55>] [<c012bd10>] [<c0105000>] Nov 30 12:06:13 lts kernel: [arch_kernel_thread+38/48] [context_thread+0/496] Nov 30 12:06:13 lts kernel: [<c0107286>] [<c012bd10>] Nov 30 12:06:13 lts kernel: Nov 30 12:06:13 lts kernel: Code: 88 1c b2 c1 fb 08 88 5c b2 01 89 f2 85 f6 79 03 8d 56 03 c1
>>>>> "Alexander" == Alexander Kuprin <ru_classic@gts.lg.ua> writes: Alexander> Добрый вечер. Alexander> Машинка с ALM 2.4. Запустил в консоли сборку LTSP. Через 10-15 Alexander> минут в логи посыпались сообщения об ошибках (файл Alexander> err.log). Ещё через пол-минуты компьютер подвис. По совету Мишы Alexander> Шигорина отключил сервис splash -- помогло. Вопрос следующий -- Alexander> на кого вешать багу? На splash или на поддержку fb в ядре? Похоже на ядро. +--------------------------------------------------------+ Grigory Milev mailto:week@altlinux.ru ALT Linux Team http://www.altlinux.ru +--------------------------------------------------------+ Life too beautiful and interesting. Don't worry, be happy.
On Friday 10 December 2004 14:03, Grigory Milev wrote: > > на кого вешать багу? На splash или на поддержку fb в ядре? > Похоже на ядро. Повесил пока сюда: https://bugzilla.altlinux.org/show_bug.cgi?id=5684 Хотя я не уверен, повторяется ли такое в текущей версии Сизифуса. А почему нет в багзилле раздела ля сообщения об ошибках в пакетах для дистрибутивов? -- WBR, Alexander Kuprin
Hi! Посмотрел lspci для этой звуковухи и не поверил - думал, сказки про коврик для мыши, найденный как SCSI-контроллер, это анекдот :)) $ lspci -vv <skip> 0000:02:04.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 (1000ns min, 6000ns max) Interrupt: pin A routed to IRQ 18 Region 0: Memory at efefb000 (32-bit, non-prefetchable) Region 1: Memory at efd00000 (32-bit, non-prefetchable) [size=1M] Capabilities: [40] AGP version 2.9 Status: RQ=1 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=<none> Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none> PS. И стало интересно, как же fglrx умудрялся заводить на этой звуковухе AGP 4x. -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov, speak to ==>JID: lakostis@jabber.org aka L.A. Kostis write to ==>mailto:lakostis@pisem.net.nospam ...The information is like the bank... (c) EC8OR
Возникла одна проблема и не могу понять, то ли я туплю, то ли что... Есть одна коммерческая программа КОДЕКС. Качество, кончено, оставляет желать лучшего. И вот какая особенность после первого останова сервиса сокет остаётся в состоянии LISTENING очень продолжительное время (более 2 суток). Вырезка из netstat --inet -lp через 2 суток после повисания КОДЕКСА и его убиения (порт 3000): tcp 0 0 *:ftp *:* LISTEN 1257/xinetd tcp 0 0 *:ssh *:* LISTEN 1275/sshd tcp 0 0 *:3000 *:* LISTEN - tcp 0 0 *:squid *:* LISTEN 1846/(squid) tcp 0 0 localhost.localdom:rndc *:* LISTEN 28086/named Это приводит к тому, что повторно демон уже не запускается. Используется ядро 2.4.29-std-up-alt3. Что интересно когда эта система стояла на 2.4.25-std-up-alt1 порт оставался в таком состоянии не более 2 минут. Такая же странность наблюдалась на ядрах 2.4.27, 2.4.28 (насчет 26 - не уверен) Это глюк в ядре, или в КОДЕКСЕ? Можно сделать чего-нибудь без перезагрузки сервака?
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --] Здравствуйте devel-kernel@, вот тот патч который _должен_ оптимизировать ядро под архитектуру то есть при сборке rpmbuild --target=... выбирать нужную архитектуру пока поддерживаются не все архитектуры, да и сам патч требует доработки, однако кое-какие результаты от его применения уже есть. Нужно добавить больше архитектур в этот список. применяется к kernel-macros в пакете kernel-build-tools-0.7-alt1 Использование: %select_arch <имя конфигурационного файла> Остался только один вопрос: как метить ядра с другой архитектурой??? И нужно ли это вообще?? обычно используется прямо перед вызовом %make_build bzImage. Смотрите прикрепленный файлы: сам патч kernel-macros.patch, пример из kernel-image-std26-up.spec для 2.6.11-alt6 С наилучшими пожеланиями, Болдин Павел. -- Болдин Павел aka davinchi ldavinchi@inbox.ru or davinchi@zu.org.ru ZU - Zagovor Unixoidov. SSAU 303. [-- Attachment #2: kernel-image-std26-up.spec --] [-- Type: text/plain, Size: 34213 bytes --] # -*- rpm-spec -*- # $Id: kernel-image-std26-up.spec,v 1.45 2005/03/18 10:43:52 vsu Exp $ # # Version options %define kernel_base_version 2.6.11 %define kernel_extra_version %nil # Numeric extra version scheme developed by Alexander Bokovoy: # 0.0.X -- preX # 0.X.0 -- rcX # 1.0.0 -- release %define kernel_extra_version_numeric 1.0.0 %define krelease alt6 %define base_flavour std26 %define flavour %base_flavour-up # Build options # You can change compiler version by editing this line: %define kgcc_version 3.3 # Enable/disable SGML docs formatting %def_enable docs # Fixes: %add_patch_list kernel-fix-build %add_patch_list kernel-fix-core %add_patch_list kernel-fix-acpi %add_patch_list kernel-fix-fs %add_patch_list kernel-fix-net #add_patch_list kernel-fix-drivers-atm %add_patch_list kernel-fix-drivers-block %add_patch_list kernel-fix-drivers-char %add_patch_list kernel-fix-drivers-net %add_patch_list kernel-fix-drivers-usb #add_patch_list kernel-fix-drivers-i2c %add_patch_list kernel-fix-drivers-ide %add_patch_list kernel-fix-drivers-ieee1394 %add_patch_list kernel-fix-drivers-input %add_patch_list kernel-fix-drivers-md %add_patch_list kernel-fix-drivers-media %add_patch_list kernel-fix-drivers-pci %add_patch_list kernel-fix-drivers-sound #add_patch_list kernel-fix-drivers-serial #add_patch_list kernel-fix-drivers-parport %add_patch_list kernel-fix-security # Features: %add_patch_list kernel-feat-drivers-drm %add_patch_list kernel-feat-drivers-video-splash %add_patch_list kernel-feat-drivers-input %add_patch_list kernel-feat-drivers-lirc %add_patch_list kernel-feat-drivers-pktcdvd %add_patch_list kernel-feat-fs-squashfs %add_patch_list kernel-feat-net-ppp-mppe %add_patch_list kernel-feat-evms-nodm # imz: Unicode support in VT/console #add_patch_list kernel-feat-drivers-console-unicode # Although this patch changes the interface between the kernel and loadkeys, # I do not put a Conflicts for the old console-tools here, # because the old loadkeys works fine the new kernel interface. ## Don't edit below this line ################################## %define kversion %kernel_base_version%kernel_extra_version Name: kernel-image-%flavour Version: %kversion Release: %krelease Summary: The Linux kernel (the core of the Linux operating system) License: GPL Group: System/Kernel and hardware Url: http://www.kernel.org/ Packager: Kernel Maintainers Team <kernel@packages.altlinux.org> Source1: config-%kernel_base_version-%flavour ExclusiveOS: Linux BuildRequires: dev86 flex BuildRequires: libdb4-devel BuildRequires: gcc%kgcc_version BuildRequires: kernel-source-%{kernel_base_version} = %{kernel_extra_version_numeric} BuildRequires: kernel-build-tools >= 0.7, modutils >= 2.4.27-alt1 BuildRequires: %get_patch_list %if_enabled docs BuildRequires: docbook-utils transfig ghostscript %endif %if_enabled ccache BuildRequires: ccache %endif %ifdef use_ccache BuildRequires: ccache %endif Requires: bootloader-utils >= 0.3-alt1 Requires: modutils >= 2.4.27-alt1 Requires: mkinitrd >= 1:2.9.2-alt1 Requires: startup >= 0.8.3-alt1 Provides: kernel = %kversion Provides: kernel-modules-drm-%flavour = %kversion Provides: kernel-modules-drm-%kversion-%flavour-%krelease = %version-%release Prereq: coreutils Prereq: modutils >= 2.4.27 Prereq: mkinitrd >= 1:2.9.2-alt1 ExclusiveArch: %ix86 %description This package contains the Linux kernel that is used to boot and run your system. It contains few device drivers for specific hardware. Most hardware is instead supported by modules loaded after booting. Patches included:%format_patch_list %package -n kernel-headers-%flavour Summary: Header files for the Linux kernel Group: System/Kernel and hardware Requires: kernel-headers-common >= 1.1.5 Provides: kernel-headers = %version %description -n kernel-headers-%flavour These are the C header files for the Linux kernel, which define structures and constants that are needed when building most standard programs under Linux, as well as to rebuild the kernel. Patches included:%format_patch_list %package -n kernel-headers-modules-%flavour Summary: Headers and other files needed for build kernel modules Group: System/Kernel and hardware Requires: kernel-headers-%flavour = %version-%release Requires: gcc%kgcc_version %description -n kernel-headers-modules-%flavour These are the C headers and other files from the Linux kernel source tree, which define structures and constants that are needed when building kernel modules only. Don't use it for any purposes except building kernel modules. %package -n kernel-doc-%base_flavour Summary: Linux kernel %kversion documentation Group: System/Kernel and hardware %description -n kernel-doc-%base_flavour This package contains documentation files for ALT Linux kernel packages: * kernel-image-%base_flavour-up-%kversion-%krelease * kernel-image-%base_flavour-smp-%kversion-%krelease %prep %setup -cT -n kernel-image-%flavour-%kversion-%krelease %__rm -rf kernel-source-%kernel_base_version %__tar -jxf %kernel_src/kernel-source-%kernel_base_version.tar.bz2 %setup -D -T -n kernel-image-%flavour-%kversion-%krelease/kernel-source-%kernel_base_version echo "patches = %_patch_list" %apply_patches 2.6 # this file should be usable both with make and sh (for broken modules # which do not use the kernel makefile system) echo 'export GCC_VERSION=%kgcc_version' > gcc_version.inc %__subst 's/EXTRAVERSION[[:space:]]*=.*/EXTRAVERSION = %kernel_extra_version-%flavour-%krelease/g' Makefile %__subst 's/CC.*$(CROSS_COMPILE)gcc/CC := $(shell echo $${GCC_USE_CCACHE:+ccache}) gcc-%kgcc_version/g' Makefile # get rid of unwanted files resulting from patch fuzz find . -name "*.orig" -delete -or -name "*~" -delete %build KERNEL_BUILD_DIR=`pwd` KernelVer=%kversion-%flavour-%krelease echo "Building Kernel $KernelVer" %__cp -vf %SOURCE1 arch/%base_arch/defconfig %make_build mrproper %make_build oldconfig ### It's a hack, but a useful hack: cmp -s .config %SOURCE1 || %__cp -vf .config %SOURCE1 %select_arch .config %make_build include/linux/version.h %make bzImage %make modules echo "Kernel built $KernelVer" %if_enabled docs # psdocs, pdfdocs don't work yet %make_build htmldocs %endif %install KernelVer=%kversion-%flavour-%krelease %__mkdir -p %buildroot/boot %__install -m644 System.map %buildroot/boot/System.map-$KernelVer %__install -m644 arch/i386/boot/bzImage %buildroot/boot/vmlinuz-$KernelVer %__install .config %buildroot/boot/config-$KernelVer %__make modules_install INSTALL_MOD_PATH=%buildroot %__install -d %buildroot%_prefix/include/linux-%version-%flavour/include pushd include %__cp -a . %buildroot%_prefix/include/linux-%version-%flavour/include popd # drivers-headers install %__install -d %buildroot%_prefix/src/linux-%version-%flavour/drivers/scsi %__install -d %buildroot%_prefix/src/linux-%version-%flavour/drivers/char/drm %__cp -a ./drivers/scsi/{{scsi,hosts,scsi_obsolete,scsi_typedefs}.h,scsi_module.c} \ %buildroot%_prefix/src/linux-%version-%flavour/drivers/scsi/ %__cp -a ./drivers/char/drm/{drm,drm_os_linux,drmP}.h \ %buildroot%_prefix/src/linux-%version-%flavour/drivers/char/drm/ pushd %buildroot%_prefix/src/linux-%version-%flavour %__ln_s -f ../../include/linux-%version-%flavour/include ./include popd #%__install -d ${RPM_BUILD_ROOT}%_prefix/src/linux-%version-%flavour/drivers/media/video #%__cp -a ./drivers/addon/bttv/{{id,bttv,bttvp,audiochip,i2c-compat,tuner,bt848}.h} \ # ${RPM_BUILD_ROOT}%_prefix/src/linux-%version-%flavour/drivers/media/video %__install -d %buildroot%_prefix/src/linux-%version-%flavour/arch/%base_arch %__install -d %buildroot%_prefix/src/linux-%version-%flavour/scripts %__install -d %buildroot%_prefix/src/linux-%version-%flavour/scripts/genksyms %__install -d %buildroot%_prefix/src/linux-%version-%flavour/scripts/basic %__install -d %buildroot%_prefix/src/linux-%version-%flavour/scripts/mod %__install -d %buildroot%_prefix/src/linux-%version-%flavour/scripts/kconfig %__cp -a ./Makefile %buildroot%_prefix/src/linux-%version-%flavour/ %__cp -a ./Module.symvers %buildroot%_prefix/src/linux-%version-%flavour/ %__cp -a ./arch/%base_arch/Makefile %buildroot%_prefix/src/linux-%version-%flavour/arch/%base_arch/ %__cp -a ./scripts/pnmtologo %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/mod/modpost %buildroot%_prefix/src/linux-%version-%flavour/scripts/mod/ %__cp -a ./scripts/mkversion %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/mod/mk_elfconfig %buildroot%_prefix/src/linux-%version-%flavour/scripts/mod/ %__cp -a ./scripts/kconfig/conf %buildroot%_prefix/src/linux-%version-%flavour/scripts/kconfig/ %__cp -a ./scripts/mkcompile_h %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/makelst %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/Makefile.modpost %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/Makefile.modinst %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/Makefile.lib %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/Makefile.clean %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/Makefile.build %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/Makefile %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/kallsyms %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/genksyms/genksyms %buildroot%_prefix/src/linux-%version-%flavour/scripts/genksyms %__cp -a ./scripts/basic/fixdep %buildroot%_prefix/src/linux-%version-%flavour/scripts/basic/ %__cp -a ./scripts/extract-ikconfig %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/conmakehash %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/checkversion.pl %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/checkincludes.pl %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/checkconfig.pl %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/bin2c %buildroot%_prefix/src/linux-%version-%flavour/scripts/ %__cp -a ./scripts/gcc-version.sh %buildroot%_prefix/src/linux-%version-%flavour/scripts/ pushd %buildroot%_prefix/src/linux-%version-%flavour ln -sf ../../include/linux-%version-%flavour/include include popd %__cp -a .config %buildroot%_prefix/src/linux-%version-%flavour/.config %__cp -a gcc_version.inc %buildroot%_prefix/src/linux-%version-%flavour/ pushd %buildroot %__rm -f %buildroot/lib/modules/$KernelVer/{build,source} %__ln_s %_prefix/src/linux-%version-%flavour/ \ %buildroot/lib/modules/$KernelVer/build popd # install documentation %if_enabled docs %__install -d %buildroot%_docdir/kernel-doc-%base_flavour-%version/ %__cp -a Documentation/* %buildroot%_docdir/kernel-doc-%base_flavour-%version/ %__install -d %buildroot%_docdir/kernel-doc-%base_flavour-%version/scsi/ for dir in aacraid; do %__install -d \ %buildroot%_docdir/kernel-doc-%base_flavour-%version/scsi/$dir/ %__cp -a drivers/scsi/$dir/README* \ %buildroot%_docdir/kernel-doc-%base_flavour-%version/scsi/$dir/ done %endif # if_enabled docs %post %post_kernel_image %kversion-%flavour-%krelease %preun %preun_kernel_image %kversion-%flavour-%krelease %post -n kernel-headers-%flavour %post_kernel_headers %kversion-%flavour-%krelease %postun -n kernel-headers-%flavour %postun_kernel_headers %kversion-%flavour-%krelease %files /boot/vmlinuz-%kversion-%flavour-%krelease /boot/System.map-%kversion-%flavour-%krelease %attr(644,root,root) /boot/config-%kversion-%flavour-%krelease /lib/modules/%kversion-%flavour-%krelease %exclude /lib/modules/%kversion-%flavour-%krelease/build %files -n kernel-headers-%flavour %dir %_prefix/include/linux-%version-%flavour %dir %_prefix/include/linux-%version-%flavour/include %_prefix/include/linux-%version-%flavour/include/acpi %_prefix/include/linux-%version-%flavour/include/asm %_prefix/include/linux-%version-%flavour/include/asm-%base_arch %_prefix/include/linux-%version-%flavour/include/asm-generic %_prefix/include/linux-%version-%flavour/include/config %_prefix/include/linux-%version-%flavour/include/linux %_prefix/include/linux-%version-%flavour/include/math-emu %_prefix/include/linux-%version-%flavour/include/net %_prefix/include/linux-%version-%flavour/include/pcmcia %_prefix/include/linux-%version-%flavour/include/scsi %_prefix/include/linux-%version-%flavour/include/video %files -n kernel-headers-modules-%flavour %_prefix/src/linux-%version-%flavour /lib/modules/%version-%flavour-%krelease/build %if_enabled docs %files -n kernel-doc-%base_flavour %doc %_docdir/kernel-doc-%base_flavour-%version %endif %changelog * Tue Mar 29 2005 Sergey Vlasov <vsu@altlinux.ru> 2.6.11-alt6 - Updated kernel-fix-security: + fixed isofs corrupted filesystem handling (CAN-2005-0815) + fixed bluetooth range checking bug (CAN-2005-0750) + fixed ext2 information leak (CAN-2005-0400) + fixed binfmt_elf DoS (CAN-2005-0749) - Updated kernel-fix-core: + fixed tasklist locking bug which caused hangs instead of reboot on SMP - Updated kernel-fix-drivers-net: + fixed missing free_irq in error path in amd8111e and via-rhine drivers + fixed check for underflow in the tun driver + fixed kernel panic on receive in the hd6457x driver - Updated kernel-fix-net: + fixed deadlock in NetROM + fixed crash when reading /proc/net/route + fixed bug in IPSEC support (__xfrm_find_acq_byseq) * Wed Mar 16 2005 Sergey Vlasov <vsu@altlinux.ru> 2.6.11-alt5 - Updated kernel-fix-security: + fix ppp_async issue (CAN-2005-0384) + fix information leak through get_task_comm() * Mon Mar 14 2005 Sergey Vlasov <vsu@altlinux.ru> 2.6.11-alt4 - 2.6.11 (really kernel-fix-* packages contain relevant patches from 2.6.11.3). - Updated kernel-fix-security: + epoll: return proper error on overflow condition - Updated kernel-fix-acpi, kernel-fix-core, kernel-fix-drivers-block, kernel-fix-drivers-md, kernel-fix-drivers-sound: - removed obsolete patches - Updated kernel-fix-build: + fix "make htmldocs" failure - Updated kernel-fix-drivers-ide: + fix no_lba48_dma flag handling in ide-disk (fixes DMA timeouts on old ALI15x3 controllers with a large disk) - Updated kernel-fix-drivers-input: + make ACPI detection of i8042 controllers ia64-only (many x86 PCs have broken BIOS tables) - Updated kernel-fix-drivers-net: + fix receive descriptor length setting in r8169 + fix sis900 oops with preempt/SMP + fix via-rhine oops on shutdown with old chips without WOL support - Updated kernel-fix-drivers-pci: + fix double free in the pciehp module - Updated kernel-fix-drivers-usb: + fix cdc-acm oopses on disconnect - Updated kernel-fix-fs: + fix stat for device nodes on cramfs - Updated kernel-fix-net: + export tcp_timer_bug_msg for modular ipv6 build - Updated kernel-feat-drivers-input: + updated trackpoint patch - removed alps patch (included in 2.6.11) - Updated kernel-feat-drivers-video-splash: + new bootsplash patch for 2.6.11 - Added kernel-fix-drivers-char: + fix bug in drm setversion ioctl which could crash the X server + fix chip type for Radeon Yi ES1000 RN50 - Added kernel-fix-drivers-media: + fix saa7110 oops on modprobe + fix i2c message flags in video drivers - Added kernel-feat-drivers-drm: + add VIA Unichrome driver (version 2.3.3) - Removed kernel-fix-drivers-atm, kernel-fix-drivers-i2c, kernel-fix-drivers-serial, kernel-fix-drivers-parport (obsolete for 2.6.11). - Modified configuration: + enabled all DRM modules (DRM sources from xorg-x11 6.8.2 no longer compile with kernel 2.6.11, but modules shipped with the kernel are new enough) - Added Provides: kernel-modules-drm-%%flavour for compatibility. * Wed Feb 09 2005 Sergey Vlasov <vsu@altlinux.ru> 2.6.10-alt3 - Build with gcc-3.4. - Added kernel-fix-drivers-atm, kernel-fix-drivers-block, kernel-fix-drivers-i2c, kernel-fix-drivers-input, kernel-fix-drivers-md, kernel-fix-drivers-pci, kernel-fix-drivers-serial; updated kernel-fix-acpi, kernel-fix-core, kernel-fix-drivers-char, kernel-fix-drivers-ide, kernel-fix-drivers-scsi, kernel-fix-drivers-sound, kernel-fix-drivers-usb: + sync with 2.6.10-as3 patchset - Modified configuration: + moved IDE support to modules + moved ext2 filesystem support to modules + disabled ALSA drivers (in-kernel version is too old, use separate kernel-modules-alsa-* packages which are updated) - Changed /lib/modules/%%version-%%flavour-%%krelease/build symlink to point to %%_usrsrc/linux-%%version-%%flavour/ and moved it to the kernel-headers-modules-%%flavour subpackage. - Added version to Provides: kernel-headers (#5872). - Updated kernel-fix-drivers-ide: + added patch to fix endless partition rescan on PCMCIA flash (#5853). * Sat Jan 08 2005 Sergey Vlasov <vsu@altlinux.ru> 2.6.10-alt2 - Removed broken symlink /lib/modules/%%version-%%flavour-%%krelease/source. - Updated kernel-fix-security: + fix uselib() issue (CAN-2004-1235) + fix expand_stack issue (CAN-2005-0001) + fix integer signedness issues in moxa, random, scsi drivers + fix RLIMIT_MEMLOCK enforcement * Wed Dec 29 2004 Sergey Vlasov <vsu@altlinux.ru> 2.6.10-alt1 - 2.6.10 - Added ccache support (was lost because of CC=gcc3.3 in the kernel makefile). - Updated kernel-fix-build, kernel-fix-drivers-net, kernel-fix-net, kernel-feat-drivers-pktcdvd: - removed obsolete patches - Updated kernel-fix-drivers-parport: + fixed parport_pc module parameters - Updated kernel-feat-drivers-video-splash: + new bootsplash patch for 2.6.10 - Updated kernel-feat-net-ppp-mppe: + updated patch to version 1.2 (fixes CryptoAPI-related bug) - Added kernel-fix-drivers-ieee1394: + remove broken MODULE_ALIAS_CHARDEV entries from ieee1394 modules (#3873) - Removed kernel-fix-drivers-serial (obsolete). - Modified configuration: + CONFIG_EDD is not set (causes boot problems, #5511) + CONFIG_APM_IGNORE_USER_SUSPEND is not set (apparently this option was set accidentally a long time ago and then forgotten) + CONFIG_GEN_RTC is not set (conflicts with the real RTC support) + CONFIG_FB_RADEON_OLD is not set (conflicts with the new radeonfb driver) + CONFIG_USB_DYNAMIC_MINORS is not set (#5484) + lots of new drivers enabled (too many to list here) * Thu Oct 28 2004 Anton Farygin <rider@altlinux.ru> 2.6.9-alt11 - fixed iptables - fixed kernel-headers for using with userspace programms (#5409) - added kernel-feat-evms-nodm patch - ppp fixed: terminate connection on hangup * Wed Oct 20 2004 Anton Farygin <rider@altlinux.ru> 2.6.9-alt10 - new version - enabled swsusp - enabled preempt * Wed Aug 18 2004 Sergey Vlasov <vsu@altlinux.ru> 2.6.8-alt9 - Added missing scripts/gcc-version.sh to kernel-headers-modules. - Removed libkconfig.so shared library to avoid extra dependencies in packages. * Mon Aug 16 2004 Anton Farygin <rider@altlinux.ru> 2.6.8-alt8 - 2.6.8 - added patch for fix typo in nfs code (2.6.8.1) - updated acpi subsystem to last stable release (20040717) - updated bootsplash * Thu Aug 05 2004 Anton Farygin <rider@altlinux.ru> 2.6.7-alt8 - Updated kernel-fix-security: + fix ppos races (CAN-2004-0415) * Thu Jun 17 2004 Anton Farygin <rider@altlinux.ru> 2.6.7-alt7 - 2.6.7 - updated bootsplash patch - added kernel-fix-drivers-net: + 2.6_50_eql-check-null.patch: add NULL checks to the eql driver + 2.6_51_airo-proc-fix.patch: fix airo /proc write breakage - added kernel-fix-drivers-usb: + 2.6_51_phidgetservo-fixes.patch: fix use of freed memory in PhidgetServo driver + 2.6_52_storage-jumpshot-fix.patch: fix size reporting in the Lexar Jumpshot CF driver; avoid "unneeded entry" message with some devices - added kernel-fix-drivers-scsi: + 2.6_50_sata_sil-mod15write.patch: fix Seagate+SiI3112 mod15write bug workaround broken by the LBA48 optimizations * Tue Jun 15 2004 Anton Farygin <rider@altlinux.ru> 2.6.6-alt6 - kernel-fix-security added: + 2.6_50_fpu-exception.patch: fix FPU exception handling DoS * Fri May 21 2004 Anton Farygin <rider@altlinux.ru> 2.6.6-alt5 - updated to last kernel-fix-ide and kernel-fix-fs patches: + 2.6_55_reiserfs-i_size-race.patch: fix reiserfs inode size update race which could lead to file corruption + 2.6_52_no-suspend-on-reboot.patch: replaced with better fix (flush drive cache on reboot) + 2.6_51_dquot_release-oops.patch: fix dquot_release oops with quota_v1 + 2.6_52_quota-recursion.patch: fixes quota recursion into filesystem + 2.6_53_quota-recursion-fix.patch: fix the recursion fix + 2.6_54_quota-v2-corruption.diff: fix possible quota_v2 files corruption when root did not have any inodes&space allocated - added kernel-feat-pktcdvd * Mon May 17 2004 Anton Farygin <rider@altlinux.ru> 2.6.6-alt4 - config tuning: CONFIG_BLK_DEV_ATIIXP=y CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_PHYSDEV=m * disabled debug on i2c * enabled ebtables * disabled CONFIG_FONT_MINI_4x6 * moved CONFIG_X86_MCE_NONFATAL to modules * disabled CONFIG_IDEDMA_IVB - added kernel-fix-drivers-ide (Sergey Vlasov) with: + 2.6_50_wcache-fixes.patch: fix write cache handling problems: + fix drive->wcache setting + send CACHE FLUSH (EXT) only if the drive claims to support it + fix for Maxtor disks falsely claiming CACHE FLUSH EXT support + 2.6_51_system_state.patch: differentiate between halt/poweroff/reboot + 2.6_52_no-suspend-on-reboot.patch: avoid drive spindown on reboot * Tue May 11 2004 Anton Farygin <rider@altlinux.ru> 2.6.6-alt3 - 2.6.6 - fixed depends (kernel-headers-modules) - added kernel-fix-acpi with: fixes IRQ12 sharing - Added kernel-feat-drivers-console-unicode by Ivan Zakharyaschev <imz@altlinux.ru>: fixes the imperfectness of Linux VT/console Unicode support (involves a change of the kernel interface used by loadkeys, but mainly is compatible with old loadkeys). * Mon Apr 05 2004 Anton Farygin <rider@altlinux.ru> 2.6.5-alt2 - fixed requires (kernel-headers-common >= 1.1.5), bugzilla #3892 * Mon Apr 05 2004 Anton Farygin <rider@altlinux.ru> 2.6.5-alt1 - 2.6.5 - added squashfs patch - enabled forcedeth driver (CONFIG_FORCEDETH=m) - added kernel-doc-std26 package - updated trackpoint patch - updated splash patch * Thu Mar 22 2004 Anton Farygin <rider@altlinux.ru> 2.6.4-alt4 - fixed requires (mkinitrd >= 2.9.1-alt1, modutils >= 2.4.27-alt1) - some cpufreq feathures moved to modules - enabled PF_KEYv2 socket family support - temporary disabled software suspend - temporary disabled PREEMPT - updated bootsplash patch from Gentoo (with fixed kernel oops on boot) - added Provides: alsa = 1.0.3 - added lirc modules - disabled drm modules * Wed Mar 17 2004 Anton Farygin <rider@altlinux.ru> 2.6.4-alt3 - removed Provides kernel-headers-std - fixed permissions for files into /boot * Thu Mar 11 2004 Anton Farygin <rider@altlinux.ru> 2.6.4-alt2 - 2.6.4 * Wed Feb 18 2004 Anton Farygin <rider@altlinux.ru> 2.6.3-alt1 - 2.6.3 * Tue Feb 17 2004 Rider <rider@altlinux.ru> 2.6.2-alt2 - removed symlinking to default kernel on post-install stage * Wed Feb 4 2004 Ed V. Bartosh <ed@altlinux.org> 2.6.2-alt1 - 2.6.2 - CONFIG_HIGHMEM4G=y (64G caused an reboot on Centrino-based notebooks) - CONFIG_MAGIC_SYSRQ=y * Tue Jan 20 2004 Ed V. Bartosh <ed@altlinux.org> 2.6.1-alt5 - evms 2.2.2 - packet CD writing support - CD-MRW (Mt Rainier) support - CONFIG_BLK_DEV_IDEPNP was turned off - some headers from ./drivers/char/drm/ added to the kernel-headers-modules - kernel-modpost package removed - xfs bug fixed * Sat Jan 17 2004 Gleb Stiblo <ulfr@altlinux.org> 2.6.1-alt4 - framebuffer added! - splash added * Thu Jan 15 2004 Ed V. Bartosh <ed@altlinux.org> 2.6.1-alt3 - initrd size increased to 12288 Kb - DM and EVMS fixes added - spec sanity check: %%defattr removed * Wed Jan 14 2004 Gleb Stiblo <ulfr@altlinux.org> 2.6.1-alt2 - some files to kernel-headers-modules - Makefiles hacks - initrd size increased to 8192 Kb * Fri Jan 9 2004 Ed V. Bartosh <ed@altlinux.org> 2.6.1-alt1 - 2.6.1 - gcc 3.3 - Default Linux Capabilities build into the kernel - NSA SELinux Support removed * Thu Jan 8 2004 Ed V. Bartosh <ed@altlinux.org> 2.6.0-alt3 - kernel-fix-security patchset added (CAN-2003-0985 mremap fix and capability fix) - NSA SELinux Support added * Tue Dec 23 2003 Ed V. Bartosh <ed@altlinux.org> 2.6.0-alt2 - IDE chipsets are compiled into the kernel now * Thu Dec 18 2003 Ed V. Bartosh <ed@altlinux.org> 2.6.0-alt1 - rebuild for 2.6.0 release - fix-core and fix-fs added * Wed Dec 17 2003 Ed V. Bartosh <ed@altlinux.org> 2.6.0test11-alt2 - symlink 'include' added to the kernel-modules-headers package * Thu Dec 4 2003 Ed V. Bartosh <ed@altlinux.ru> 2.6.0test11-alt1 - 2.6test11 - spec improvements - 'kernel-modpost' package added * Sat Nov 29 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt12 - Updated kernel-fix-security: + fixed CAN-2003-0001, CAN-2003-0461, CAN-2003-0961 * Fri Nov 28 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt11 - Updated kernel-fix-fs: + fixed iso9660 mount options handling - Added kernel-fix-security. - Updated kernel-feat-acpi: + new ACPI patch (ACPI hotplug fix, pci=noacpi fix) - Updated kernel-feat-cpufreq: + speedstep-smi driver fixes - Updated kernel-feat-drivers-libata: + updated libata patch to 2.4.23-rc3-libata1: - fixed a bug which may cause some devices to "not be talked to" at probe time (fixed flush of Device Control register to device) - ServerWorks-specific tweaks + added Intel Software RAID (ICH5R) support (iswraid module) - Modified security configuration: + Non-executable user stack area enabled (with GCC trampolines autodetection): CONFIG_HARDEN_STACK=y, CONFIG_HARDEN_STACK_SMART=y + Restricted /proc enabled: CONFIG_HARDEN_PROC=y * Wed Nov 19 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt10 - Fixed file lists for kernel-headers-%%flavour: + added acpi/, crypto/, freeswan.h, freeswan/, pfkey.h, pfkeyv2.h, zlib/ - Fixed kernel-headers-modules-%%flavour dependencies. - Modified configuration: - adma100, sc1200, siimage drivers are now built into the kernel (building IDE controller drivers as modules does not work unless the whole IDE subsystem is in modules too) - tvmixer module is not built (now it is in kernel-modules-v4l-%%flavour) - Added kernel-fix-drivers-pnp: + fixed problems with detection of some ISA PnP cards - Updated kernel-fix-drivers-net: + fixed multicast list handling in the tulip driver - Updated kernel-fix-drivers-scsi: + sg driver bugfix: do not accept negative sizes in SG_SET_RESERVED_SIZE - Updates kernel-fix-fs: + fixed quota stats accounting bug + fixed races on inode deletion (could cause oops with NFS) - Updated kernel-feat-acpi: + new ACPI patch (IRQ assignment fixes, poweroff fix) - Updated kernel-feat-drivers-libata: + new upstream version (Promise driver bugfixes) + added support for Promise FastTrak 376 * Sat Nov 15 2003 Albert R. Valiev <darkstar@altlinux.ru> 2.4.22-alt9 - Added kernel-feat-driver-net-pcnet32-old patch - fix for vmware network card driver * Sun Nov 09 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt8 - Updated kernel-feat-acpi (ACPI updates and fixes, Alt-SysRq poweroff fix). - Updated kernel-feat-drivers-libata (new version, Promise SATA driver significantly enhanced). - Updated kernel-fix-drivers-scsi (updated ServeRAID and MegaRAID drivers, SCSI blacklist updates). - Added kernel-fix-drivers-cdrom (bugfixes). - Updated kernel-fix-core, kernel-fix-drivers-char, kernel-fix-drivers-ide, kernel-fix-drivers-ieee1394, kernel-fix-drivers-net, kernel-fix-drivers-pci, kernel-fix-drivers-sound, kernel-fix-drivers-usb, kernel-fix-fs, kernel-fix-lvm, kernel-fix-net (lots of bugfixes). - Relaxed BuildRequires (libdb4.0-devel -> libdb4-devel) (#2826). * Sun Oct 19 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt7 - Updated kernel-feat-acpi (important bugfixes; enabled DMI info dump; moved ACPI BIOS date cutoff from 2001 to 2000). - Added kernel-fix-lvm (makes LVM snapshots work with journaling FS). - Added documentation subpackage (common for std-up and std-smp flavours). - Added kernel-feat-libata (Serial ATA drivers). Supported devices: Intel ICH5, Promise FastTrak S150 TX2plus/TX4/SX4, Broadcom (Apple K2) SATA, VIA SATA. Silicon Image SATA support not enabled (does not work yet). - Updated kernel-feat-i2c (2.8.1 release). * Tue Oct 07 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt6 - updated kernel-feat-net-ppp-mppe (this version should really work) - updated kernel-feat-crypto: - back to old cryptoapi from kerneli.org - moved .config to kernel-headers-modules - added toplevel Makefile and Rules.make to kernel-headers-modules (needed for compilation of some external modules) - added kernel-feat-cpufreq (frequency/voltage scaling support) - removed kernel-feat-bttv, kernel-feat-saa7134 (now in kernel-modules-v4l) - removed kernel-feat-addon (no longer used) - updated kernel-feat-acpi (more fixes) - turned off OV511 USB camera driver (now in kernel-modules-v4l) * Mon Sep 29 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt5 - updated kernel-fix-net: - hidden IGMPv3 definitions in <linux/in.h> from userspace (workaround for #3053) - updated kernel-fix-drivers-usb, kernel-feat-drivers-usb: - lots of bugfixes and new device IDs - updated kernel-fix-drivers-char: - added AGP support for Intel 875 (integrated video not supported) - fixed kernel-headers-modules building: - install updated bttv headers instead of obsolete ones * Wed Sep 24 2003 Sergey Vlasov <vsu@altlinux.ru> 2.4.22-alt4 - added kernel-feat-acpi: + ACPI update 20030916-2.4.22 (should fix some problems with nForce) + DSDT override from initrd + blacklist updates - added kernel-fix-drivers-mtd, kernel-fix-drivers-sound, kernel-fix-drivers-video: + missing MODULE_LICENSE fixes - updated kernel-fix-drivers-char: + fixed AGP 3.0 support for Via KT400 + added AGP support for Intel 7x05, ATI Radeon IGP, Via CLE266 - updated kernel-fix-drivers-pci: + enable SMBus controller on ASUS boards - added kernel-headers-modules-%flavour package (Rider) - added provides: kernel24-headers (Rider) - added kernel-feat-drivers-sound-emu10k1 (Rider) + update emu10k1 to 0.20a - added drivers/media/video/ headers to kernel-headers-modules package (Rider) - disabled 8139cp (PCI ID conflict with 8139too) - added kernel-fix-drivers-ieee1394, kernel-fix-drivers-atm * Thu Sep 11 2003 Anton Farygin <rider@altlinux.ru> 2.4.22-alt3 - enabled aic79xx module by default - updated sk98lin driver for support 3c940 and other (based on sk98) ethernet cards - enabled CONFIG_4GB option - build ATM support for UP kernel * Tue Sep 09 2003 Anton Farygin <rider@altlinux.ru> 2.4.22-alt2 - fixed bug with build userspace v4l programms * Tue Sep 02 2003 Rider <rider@altlinux.ru> 2.4.22-alt1 - update to 2.4.22 - removed ACPI patches (mainstream) - removed O(1)sheduler * Tue Aug 26 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt14 - played with OWL patch configs. installator should work just fine now. * Thu Aug 14 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt13 - added Video4Linux Version 2 API patch. - added kernel-fix-drivers-md. - added saa7134 driver. * Wed Aug 13 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt12 - removed percentexclude pcmcia dir. * Mon Aug 11 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt11 - getting back bttv. * Mon Aug 11 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt10 - upgraded patches. - added patches: + kernel-fix-drivers-char + kernel-fix-drivers-video - temporary removed patches: - kernel-feat-bttv * Thu Aug 07 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt9 - got back all the pcmcia inkernel drivers, as 3.2.4 are considered as experimental. * Thu Jul 31 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt8 - added kernel-headers to provides of kernel-headers-%{flavour}. - replaced get_patch_list with format_patch_list. - rebuilt with new kernel-fix-core with new dcache names patch. start-stop-daemon should work now. - added asm-generic directory to headers. - don't build pcmcia modules inside the kernel. * Wed Jul 30 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt7 - removed iscsi patch as rider@ and ab@ suggested. * Thu Jul 17 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt6 - Added provides kernel24 - ACPI support now included (+ kernel-feat-acpi) - Fixed OWL security patch configuration, proc is now visible to all in std kernels. * Tue Jul 15 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt5 - new patches: + kernel-fix-fs * Wed Jul 09 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt4 - compiled Promise PDC drivers in kernel (satisfying request by mouse@a.r). * Mon Jul 07 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt3 - new patches: + kernel-fix-drivers \ + ide + net + pci + scsi + usb + security-owl + kernel-feat \ + fs-ntfs + i2c - fixed spec in many places - changed /etc/apt/apt.cond.d/file filename so that kernel packages with different versions installed at one time don't conflict. * Sat Jun 21 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rel-alt1 - upgraded to rc7 - applied patches: + kernel-fix-core + kernel-feat-core-O1sched + kernel-feat-iscsi + kernel-feat-bttv + kernel-feat-fs-xfs + kernel-feat-kconfig + kernel-feat-addon + kernel-feat-crypto + kernel-feat-drivers-video-splash + kernel-feat-net-ipsec \ + ipsec + ppp-mppe * Mon May 26 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rc1-alt3 - compile ext2 filesystem in kernel for installer needs. - added net-ipsec and video-splash features. * Thu May 15 2003 Peter Novodvorsky <nidd@altlinux.com> 2.4.21rc1-alt2 - removed crypto patch because it bugs loop filesystem. ... And added it again, because it doesn't. * Fri Apr 25 2003 Peter Novodvorsky <nidd@altlinux.com> kernel-policy-rc.2 - rc2 policy release. [-- Attachment #3: kernel-macros.patch --] [-- Type: text/x-patch, Size: 1035 bytes --] --- /etc/rpm/macros.d/kernel 2004-08-03 20:26:11 +0500 +++ kernel 2005-04-05 13:06:06 +0500 @@ -106,6 +106,28 @@ for f in %_patch_list ; do \ done \ %nil +# Selecting arch +%select_arch() \ +echo "Checking aliases for " %_arch "..." \ +%__subst 's,^\\(CONFIG_M586\\)=y.*$,# \\1 is not set,' %1 \ +NEW_ARCH=$(echo %_arch | \ + sed -e 's/i386/CONFIG_M386/g;s/i486/CONFIG_M486/g;s/i586/CONFIG_M586/g' | \ + sed -e 's/i686/CONFIG_M686/g;s/p\\(entium\\)\\{0,1\\}2/CONFIG_MPENTIUMII/g' | \ + sed -e 's/p\\(entium\\)\\{0,1\\}3/CONFIG_MPENTIUMIII/g' | \ + sed -e ';s/p\\(entium\\)\\{0,1\\}4/CONFIG_MPENTIUM4/g' | \ + sed -e 's/k6.*/CONFIG_MK6/g;s/athlon.*/CONFIG_MK7/g') \ +if [ "x$NEW_ARCH" = "x%_arch" ]; then \ + echo "No such architecture: %_arch" \ + echo "Using default" \ + NEW_ARCH=""; \ +fi \ +if [ "x$NEW_ARCH" = "x" ]; then \ + NEW_ARCH=CONFIG_M586; \ +fi \ +%__subst "s,.*$NEW_ARCH.*,$NEW_ARCH=y,g" %1 \ +%nil + + # Standard way for installing patches %install_patches \ %__mkdir_p %patches_dir/%patch_name \
Кто пробовал? http://www.gridmpi.org/pspacer-1.0/index.en.jsp Группа японских ученых представила первую версию пакета PSPacer, распространяемого в рамках лицензии GPL и предназначенного для точного и аккуратного лимитирования трафика, исключающего потерю пакетов. В состав PSPacer входит модуль для Linux ядер 2.4/2.6, и библиотека для управления через стандартный интерфейс iproute2 ("tc qdisc", Linux Queueing Discipline (Qdisc)). -- <взято отюда> http://www.opennet.ru/opennews/art.shtml?num=5695
...ещё добавим макросы по сборке ядер под разные рахитектуры. Сейчас это немного затормаживает появление x86_64 ядра как оно должно быть "по инструкции". А ещё нужно расширять спеки на тему ExclusiveArch. Вопрос с многоарчностью я уже поднимал несколько раз, даже что-то предлагал, но особого оживления не возникло. В пятницу Сизиф потолстел на добрых пол гига, вместив в себя небольшой набор пакетов под x86_64. -- mouse
[-- Attachment #1: Type: text/plain, Size: 911 bytes --] On Sun, Jul 10, 2005 at 10:19:05PM +0400, Anton D. Kachalov wrote: > ...ещё добавим макросы по сборке ядер под разные рахитектуры. Сейчас это > немного затормаживает появление x86_64 ядра как оно должно быть "по инструкции". > А ещё нужно расширять спеки на тему ExclusiveArch. Причём в ядре нужно писать в ExclusiveArch только те варианты архитектур, для которых есть файлы конфигурации. Сейчас можно пересобрать kernel-image-* с --target pentium4 или ещё каким-то другим вариантом, но ожидаемого результата это не даст - лучше уж явно это запретить. В kernel-modules-* независимо от того, что указано в --target, оптимизация и набор команд получатся те, которые были использованы при сборке соответствующего ядра. Можно ли тут сделать жёсткую привязку, чтобы не создавать пакетов с "неправильной" архитектурой - надо подумать. Хотя любителей такой оптимизации можно и проигнорировать... [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Прошу принять меня в kernel team. С августа прошлого года поддерживаю пакет kernel-feat-fs-reiser4. Также хотел бы соучаствовать в архитектуре xen для alt. Сергей Иванов
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --] Hi! Сегодня собирал один сервер, и столкнулся с еще одним китайским приколом (о первом приколе я уже писал в свое время, когда у звуковой карты с появилось agp). Теперь прикол еще приколистее - вместо сетевухи получил некий мультимедиа контроллер :-( ) Без шуток: $ lspci -v 0000:02:0a.0 Multimedia video controller: Gammagraphx, Inc.: Unknown device 0400 (rev 08) Subsystem: Unknown device 002c:0400 Flags: bus master, slow devsel, latency 0 Memory at <ignored> (32-bit, non-prefetchable) [disabled] Memory at <ignored> (64-bit, non-prefetchable) [disabled] Memory at <ignored> (64-bit, prefetchable) [disabled] Memory at <invalid-64bit-slot> (64-bit, non-prefetchable) [disabled] А на коробке написано Compex ethernet adapter на базе rtl8139. Видимо китайцы на производстве правильную траву нюхают, что такие поделия выпускают. -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov, speak to ==>JID: lakostis@jabber.org aka L.A. Kostis write to ==>mailto:lakostis@pisem.net.nospam ...The information is like the bank... (c) EC8OR [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --] On Sun, Aug 07, 2005 at 06:22:01PM +0400, Konstantin A. Lepikhov wrote: > Сегодня собирал один сервер, и столкнулся с еще одним китайским приколом > (о первом приколе я уже писал в свое время, когда у звуковой карты с > появилось agp). Теперь прикол еще приколистее - вместо сетевухи получил > некий мультимедиа контроллер :-( ) Без шуток: > > $ lspci -v > 0000:02:0a.0 Multimedia video controller: Gammagraphx, Inc.: Unknown device 0400 (rev 08) > Subsystem: Unknown device 002c:0400 > Flags: bus master, slow devsel, latency 0 > Memory at <ignored> (32-bit, non-prefetchable) [disabled] > Memory at <ignored> (64-bit, non-prefetchable) [disabled] > Memory at <ignored> (64-bit, prefetchable) [disabled] > Memory at <invalid-64bit-slot> (64-bit, non-prefetchable) [disabled] > > А на коробке написано Compex ethernet adapter на базе rtl8139. Видимо > китайцы на производстве правильную траву нюхают, что такие поделия > выпускают. Если криво вставить плату, можно и не такое получить :) А вот что курили разработчики чипсета nForce4, когда решили присвоить встроенной сетевухе класс Bridge (0x0680) - это действительно загадка. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 950 bytes --] Думаю вопрос всё-таки скорее сюда..чем в рассылки sisyphus. Дано: Срез сизифа за август. решил собрать свежее wks-ядро с оптимизацией под AMD. В спеке изменил: %set_kernel_arches i586 на %set_kernel_arches i586 athlon и %make_build oldconfig на %make_build menuconfig Дифф между конфигом ядра из пакета -kernel-image-wks26-up.src.rpm и тем что у меня в аттаче. Собирал как rpm -ba --target athlon kernel.spec Но не собралось.. последние слова: + /bin/install -Dp -m644 scripts/kconfig/conf /home/stalker/tmp/kernel-image-wks26-up-buildroot/usr/src/linux-2.6.12-wks26-up/scripts/kconfig/conf /bin/install: cannot stat `scripts/kconfig/conf': No such file or directory ошибка: Неверный код возврата из /home/stalker/tmp/rpm-tmp.62797 (%install) Ошибки сборки пакетов: Неверный код возврата из /home/stalker/tmp/rpm-tmp.62797 (%install) Такого файла действительно нет. Вопрос тривиальный -что делать и кто виноват. -- np: silence [-- Attachment #2: diff --] [-- Type: text/plain, Size: 2098 bytes --] --- config-2.6.12-wks26-up.i586.old 2005-08-08 19:39:33 +0400 +++ .config 2005-09-12 23:59:45 +0400 @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-wks26-up-alt4 -# Sat Aug 6 14:38:15 2005 +# Mon Sep 12 23:59:45 2005 # CONFIG_X86=y CONFIG_MMU=y @@ -22,7 +22,6 @@ # General setup # CONFIG_LOCALVERSION="" -CONFIG_HERTZ=1000 CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y @@ -77,7 +76,7 @@ # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set -CONFIG_M586=y +# CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set @@ -86,7 +85,7 @@ # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set -# CONFIG_MK7 is not set +CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set @@ -102,17 +101,15 @@ CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y -CONFIG_X86_PPRO_FENCE=y -CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y -CONFIG_X86_ALIGNMENT_16=y +CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y +CONFIG_X86_USE_PPRO_CHECKSUM=y +CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y -CONFIG_NO_IDLE_HZ=y -CONFIG_DYN_TICK_USE_APIC=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y @@ -120,11 +117,12 @@ CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y +CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=m -CONFIG_X86_MCE_P4THERMAL=y -CONFIG_TOSHIBA=m -CONFIG_I8K=m +# CONFIG_X86_MCE_P4THERMAL is not set +# CONFIG_TOSHIBA is not set +# CONFIG_I8K is not set CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=m CONFIG_X86_MSR=m @@ -2655,7 +2653,9 @@ # CONFIG_JFFS2_CMODE_SIZE is not set CONFIG_CRAMFS=m CONFIG_SQUASHFS=m -# SQUASHFS_EMBEDDED is not set +# CONFIG_SQUASHFS_EMBEDDED is not set +CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 +# CONFIG_SQUASHFS_VMALLOC is not set CONFIG_VXFS_FS=m CONFIG_HPFS_FS=m CONFIG_QNX4FS_FS=m
Антон Горлов пишет: > Думаю вопрос всё-таки скорее сюда..чем в рассылки sisyphus. > > /bin/install: cannot stat `scripts/kconfig/conf': No such file or directory > ошибка: Неверный код возврата из /home/stalker/tmp/rpm-tmp.62797 (%install) > Ошибки сборки пакетов: > Неверный код возврата из /home/stalker/tmp/rpm-tmp.62797 (%install) > Что-то вы не так собираете. Как впрочем и я. У меня тоже всегда в этом месте ругается. Просто в spec-файле нужно закомментировать строчку с "kconfig/conf". После этого все собирается, последствий негативных не обнаружено. -- Alexei V. Mezin NT-MDT Co. Phone: 095-913-5736 Fax: 095-913-573 Email: mezin@ntmdt.ru URL: http://www.ntmdt.com
Alexei V. Mezin пишет:
>> /bin/install: cannot stat `scripts/kconfig/conf': No such file or
>> directory
>> ошибка: Неверный код возврата из /home/stalker/tmp/rpm-tmp.62797
>> (%install)
>> Ошибки сборки пакетов:
>> Неверный код возврата из /home/stalker/tmp/rpm-tmp.62797 (%install)
> Что-то вы не так собираете. Как впрочем и я. У меня тоже всегда в этом
> месте ругается. Просто в spec-файле нужно закомментировать строчку с
> "kconfig/conf". После этого все собирается, последствий негативных не
> обнаружено.
wRAR посоветовал заменить scripts/kconfig/conf на
scripts/kconfig/mconf...типа имя зависит от того как конфигуряли
--
np: Masterplan - I'm Not Afraid
[-- Attachment #1: Type: text/plain, Size: 418 bytes --] On Tue, Sep 13, 2005 at 02:19:37PM +0400, Антон Горлов wrote: > wRAR посоветовал заменить scripts/kconfig/conf на > scripts/kconfig/mconf...типа имя зависит от того как конфигуряли Притом сам wRAR строчку просто комментирует, проблем пока не наблюдалось. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): новый udev предлагает прекрасные возможности для таких хаков -- rider in #7085 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Здравствуйте. буре исходники ядра, накладываю нужный патчик, смотрю config-2.4.26-std-up-alt6 весит 46670, конфиг, получаемый путем его загрузки, включения 3-х опций с последующим сохранением - 42476. в каком месте кривые руки? -- С уважением, Andrey A. Yefremov mailto:alt@techno.dn.ua
[-- Attachment #1: Type: text/plain, Size: 446 bytes --] Andrey A. Yefremov пишет: > Здравствуйте. > > буре исходники ядра, накладываю нужный патчик, смотрю > config-2.4.26-std-up-alt6 весит 46670, конфиг, получаемый путем его > загрузки, включения 3-х опций с последующим сохранением - 42476. в > каком месте кривые руки? А вы наложили ВСЕ патчи которые накладываются в std-up ? Их там много... Hint: rpm -ivh kernel-image-XXX.src.rpm cd ~/RPM/SPECS/ rpm -bp kernel-image-XXX.spec [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Блин, люди, помогите, плиз, нубу, совсем сбился. Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно дистр лежал подаренный, как раз win рухнула, решил перебраться на линукс. В общем, нужно пересобрать ядро для включения atm, что в свою очередь необходимо для настройки выхода в сеть (девайс требует atm'a в ядре). menu xconfig плюётся тем, что qt не инсталлирован: * Unable to find the QT installation. Please make sure that the * QT development package is correctly installed and the QTDIR * environment variable is set to the correct location. хотя вроде qt поставлен. Ладно, слил себе qt3, так тот уже на configure блюёт этим: g++ -c -o project.o -I. -Igenerators -Igenerators/unix -Igenerators/win32 -Igenerators/mac -I/usr/local/qt/include/qmake -I/usr/local/qt/include -I/usr/local/qt/include -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_COMPONENT -DQT_NO_STL -DQT_NO_COMPRESS -I/usr/local/qt/mkspecs/linux-g++ -DHAVE_QCONFIG_CPP project.cpp /usr/bin/i586-alt-linux-g++: No such file or directory gmake: *** [project.o] Ошибка 1 Что за i586-alt-linux-g++ - не постиг. gcc? есть. Но всё равно тоже слил. Тот при на make говорит: bin/sh ./../missing flex -ogengtype-lex.c gengtype-lex.l WARNING: `flex' is missing on your system. You should only need it if you modified a `.l' file. You may need the `Flex' package in order for those modifications to take effect. You can get `Flex' from any GNU archive site. bison -d -o gengtype-yacc.c gengtype-yacc.y make[1]: bison: Команда не найдена make[1]: [gengtype-yacc.h] Ошибка 127 (игнорирована) gcc -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -I. -I. -I./. -I./../include \ gengtype-lex.c -o gengtype-lex.o i586-alt-linux-gcc: gengtype-lex.c: No such file or directory i586-alt-linux-gcc: no input files make[1]: *** [gengtype-lex.o] Ошибка 1 make[1]: Leaving directory `/root/RPM/SOURCES/gcc-3_4-rhl-branch-200506080740/gcc' make: *** [all-gcc] Ошибка 2 Ну да ладно, пробовал при пересборке ядра make menuconfig - ему нужен Ncurses. Оно ругается этим: make[1]: Entering directory `/pub/Linux/ncurses-5.4/c++' cd ../objects; /usr/bin/g++ -I../c++ -I../include -I. -DHAVE_CONFIG_H -I. -I../include -D_GNU_SOURCE -DNDEBUG -c ../c++/cursesf.cc /usr/bin/i586-alt-linux-g++: No such file or directory make[1]: *** [../objects/cursesf.o] Ошибка 1 make[1]: Leaving directory `/pub/Linux/ncurses-5.4/c++' make: *** [all] Ошибка 2 Опять ...linux-g++ Одним словом, WTF? oldconfig это конечно здорово, так ядро тоже собрать можно, но всё-таки хочется пофиксить проблемы с qt, ncurses и раскурить смысл i586-alt-linux-g++
On Fri, 07 Oct 2005 18:49:25 +0400
Sphinx wrote:
> Блин, люди, помогите, плиз, нубу, совсем сбился.
> Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно дистр
> лежал подаренный, как раз win рухнула, решил перебраться на линукс.
> В общем, нужно пересобрать ядро для включения atm, что в свою очередь
>
> необходимо для настройки выхода в сеть (девайс требует atm'a в ядре).
А может не стоит тратить время на рукоблудство, и попробовать загрузить
из /lib/modules/<kernel-version>/kernel/drivers/atm модуль для
требуемого девайса?
Sphinx пишет:
> Блин, люди, помогите, плиз, нубу, совсем сбился.
> Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно дистр
> лежал подаренный, как раз win рухнула, решил перебраться на линукс.
> В общем, нужно пересобрать ядро для включения atm, что в свою очередь
> необходимо для настройки выхода в сеть (девайс требует atm'a в ядре).
Что за девайс? (Не из семейства ли USB ADSL, случаем?)
--
С уважением. Алексей.
On Fri, 07 Oct 2005 19:12:09 +0400, Aleksey Avdeev <solo@solin.spb.ru>
wrote:
> Sphinx пишет:
>> Блин, люди, помогите, плиз, нубу, совсем сбился.
>> Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно дистр
>> лежал подаренный, как раз win рухнула, решил перебраться на линукс.
>> В общем, нужно пересобрать ядро для включения atm, что в свою очередь
>> необходимо для настройки выхода в сеть (девайс требует atm'a в ядре).
>
> Что за девайс? (Не из семейства ли USB ADSL, случаем?)
>
Да, он самый. В манах прочитал, что для корректной работы необходимо
включение atm в керне, потому и мучаюсь.
Да и вообще интересно понять, wtf оно не пашетъ.
Sphinx пишет:
> On Fri, 07 Oct 2005 19:12:09 +0400, Aleksey Avdeev <solo@solin.spb.ru>
> wrote:
>
>> Sphinx пишет:
>>
>>> Блин, люди, помогите, плиз, нубу, совсем сбился.
>>> Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно дистр
>>> лежал подаренный, как раз win рухнула, решил перебраться на линукс.
>>> В общем, нужно пересобрать ядро для включения atm, что в свою
>>> очередь необходимо для настройки выхода в сеть (девайс требует
>>> atm'a в ядре).
>>
>>
>> Что за девайс? (Не из семейства ли USB ADSL, случаем?)
>>
>
>
> Да, он самый. В манах прочитал, что для корректной работы необходимо
> включение atm в керне, потому и мучаюсь.
> Да и вообще интересно понять, wtf оно не пашетъ.
А какой именно? (Для части -- уже есть готовые рецепты в
дистрибутиве.)
--
С уважением. Алексей.
On Fri, 07 Oct 2005 20:31:17 +0400, Aleksey Avdeev <solo@solin.spb.ru>
wrote:
> Sphinx пишет:
>> On Fri, 07 Oct 2005 19:12:09 +0400, Aleksey Avdeev <solo@solin.spb.ru>
>> wrote:
>>
>>> Sphinx пишет:
>>>
>>>> Блин, люди, помогите, плиз, нубу, совсем сбился.
>>>> Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно дистр
>>>> лежал подаренный, как раз win рухнула, решил перебраться на линукс.
>>>> В общем, нужно пересобрать ядро для включения atm, что в свою
>>>> очередь необходимо для настройки выхода в сеть (девайс требует
>>>> atm'a в ядре).
>>>
>>>
>>> Что за девайс? (Не из семейства ли USB ADSL, случаем?)
>>>
>> Да, он самый. В манах прочитал, что для корректной работы необходимо
>> включение atm в керне, потому и мучаюсь.
>> Да и вообще интересно понять, wtf оно не пашетъ.
>
> А какой именно? (Для части -- уже есть готовые рецепты в
> дистрибутиве.)
>
Zyxel Omni ADSL USB
"Стрим" необходимо настроить в общем.
Sphinx пишет: > On Fri, 07 Oct 2005 20:31:17 +0400, Aleksey Avdeev <solo@solin.spb.ru> > wrote: > >> Sphinx пишет: >> >>> On Fri, 07 Oct 2005 19:12:09 +0400, Aleksey Avdeev >>> <solo@solin.spb.ru> wrote: >>> >>>> Sphinx пишет: >>>> >>>>> Блин, люди, помогите, плиз, нубу, совсем сбился. >>>>> Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно >>>>> дистр лежал подаренный, как раз win рухнула, решил перебраться >>>>> на линукс. >>>>> В общем, нужно пересобрать ядро для включения atm, что в свою >>>>> очередь необходимо для настройки выхода в сеть (девайс требует >>>>> atm'a в ядре). >>>> >>>> >>>> >>>> Что за девайс? (Не из семейства ли USB ADSL, случаем?) >>>> >>> Да, он самый. В манах прочитал, что для корректной работы >>> необходимо включение atm в керне, потому и мучаюсь. >>> Да и вообще интересно понять, wtf оно не пашетъ. >> >> >> А какой именно? (Для части -- уже есть готовые рецепты в >> дистрибутиве.) >> > > > Zyxel Omni ADSL USB > "Стрим" необходимо настроить в общем. Тогда всё просто: <http://www.freesource.info/wiki/Stat'i/NastrojjkaInterneta/ADSL> (в крайнем случаи -- что-то под Мастер пересобрать). PS: Тема для hardware@ -- С уважением. Алексей.
On Fri, 07 Oct 2005 21:12:38 +0400, Aleksey Avdeev <solo@solin.spb.ru>
wrote:
> Sphinx пишет:
>> On Fri, 07 Oct 2005 20:31:17 +0400, Aleksey Avdeev <solo@solin.spb.ru>
>> wrote:
>>
>>> Sphinx пишет:
>>>
>>>> On Fri, 07 Oct 2005 19:12:09 +0400, Aleksey Avdeev
>>>> <solo@solin.spb.ru> wrote:
>>>>
>>>>> Sphinx пишет:
>>>>>
>>>>>> Блин, люди, помогите, плиз, нубу, совсем сбился.
>>>>>> Меньше недельки назад завёл пингвина, ALT Linux 2.4 JR. Давно
>>>>>> дистр лежал подаренный, как раз win рухнула, решил перебраться
>>>>>> на линукс.
>>>>>> В общем, нужно пересобрать ядро для включения atm, что в свою
>>>>>> очередь необходимо для настройки выхода в сеть (девайс требует
>>>>>> atm'a в ядре).
>>>>>
>>>>>
>>>>>
>>>>> Что за девайс? (Не из семейства ли USB ADSL, случаем?)
>>>>>
>>>> Да, он самый. В манах прочитал, что для корректной работы
>>>> необходимо включение atm в керне, потому и мучаюсь.
>>>> Да и вообще интересно понять, wtf оно не пашетъ.
>>>
>>>
>>> А какой именно? (Для части -- уже есть готовые рецепты в
>>> дистрибутиве.)
>>>
>> Zyxel Omni ADSL USB
>> "Стрим" необходимо настроить в общем.
>
> Тогда всё просто:
> <http://www.freesource.info/wiki/Stat'i/NastrojjkaInterneta/ADSL> (в
> крайнем случаи -- что-то под Мастер пересобрать).
>
> PS: Тема для hardware@
>
Блин, пасибо огромное!
Ранее читал эту статью, даже слил src.rpm amedyn'а, но поставить не смог
(не судьба мне нормально ставить из сорцов что-то). В общем, слил нужное
из дистрибутива ALM.
Ещё раз - шпекты.
Добрый день! Собирал пакет для сизифа, модуль ядра. Для компиляции ему нужны исходники ядра. В какой директории их искать (если они вообще есть)? По-умолчанию он их ищет в /usr/src/linux и не находит судя по логам робота. Заранее благодарен. --- С уважением, Авраменко Андрей
> Собирал пакет для сизифа, модуль ядра. Для компиляции ему нужны
> исходники ядра. В какой директории их искать (если они вообще есть)?
> По-умолчанию он их ищет в /usr/src/linux и не находит судя по логам
> робота.
Не исходники, а заголовки.
kernel-headers-modules-std-up
kernel-headers-modules-std-smp
[...]
--
DO4-UANIC
Denis Ovsienko wrote:
>>Собирал пакет для сизифа, модуль ядра. Для компиляции ему нужны
>>исходники ядра. В какой директории их искать (если они вообще есть)?
>>По-умолчанию он их ищет в /usr/src/linux и не находит судя по логам
>>робота.
>>
>>
>Не исходники, а заголовки.
>kernel-headers-modules-std-up
>kernel-headers-modules-std-smp
>[...]
>
>
>
Кхм... Извините, что вмешиваюсь. Ведь для сборки модулей ядра 2.6
необходимы не только заголовки, но и сама сборочная система, имеющаяся в
исходниках ядра... Или в Сизифе на этот счет - свои технологии?
Rgds, Artem.
> >>Собирал пакет для сизифа, модуль ядра. Для компиляции ему нужны
> >>исходники ядра. В какой директории их искать (если они вообще есть)?
> >>По-умолчанию он их ищет в /usr/src/linux и не находит судя по логам
> >>робота.
> >Не исходники, а заголовки.
> >kernel-headers-modules-std-up
> >kernel-headers-modules-std-smp
> Кхм... Извините, что вмешиваюсь. Ведь для сборки модулей ядра 2.6
> необходимы не только заголовки, но и сама сборочная система, имеющаяся в
> исходниках ядра... Или в Сизифе на этот счет - свои технологии?
редкая птица долетит до ... :)
т.е. редкий модуль требует для себя всех исходников ядра.
Достаточно одной таблетки :)
т.е. достаточно headers.
посмотрите как делаются другие модули.
сначала делаете module-source, потом сам модуль. если надо патчить
ядро - заливаешь fix или feat.
есть же kernel policy.
--
Alexey Shabalin
[-- Attachment #1: Type: text/plain, Size: 524 bytes --] On Tue, Nov 08, 2005 at 03:48:19PM +0300, Авраменко Андрей wrote: > Может быть я чего-то не понимаю, http://www.dazuko.org/howto-install.shtml > Там в скрипте ./configure есть опция указания пути к исходным текстам > ядра. Что ему подсунуть вместо этого? /usr/include/linux ? /usr/src/linux-версия Поставив kernel-headers-modules предварительно. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): Просто не хочу - это не аргумент в администировании компьютерных систем. -- ldv in sisyphus@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 549 bytes --] On Tue, Nov 08, 2005 at 03:38:47PM +0200, Artem wrote: > Кхм... Извините, что вмешиваюсь. Ведь для сборки модулей ядра 2.6 > необходимы не только заголовки Которые kernel-headers > , но и сама сборочная система, имеющаяся в исходниках ядра... Которая kernel-headers-modules > Или в Сизифе на этот счет - свои технологии? Конечно. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): > Люблю работающие программы. :) В фортунки, однозначно :) ...опять не член тим? :( Ну что за фигня... -- ktirf in sisyphus@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 466 bytes --] On Tue, Nov 08, 2005 at 06:14:20PM +0300, Alexey Shabalin wrote: > т.е. редкий модуль требует для себя всех исходников ядра. Мне неизвестны модули, не собирающиеся с нашими kernel-headers-modules. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): Спасибо за разъяснение. Теперь осознал. Свойство кругозора быть ограниченным вело к тому, что некоторые проблемы казались несущественными, или их вообще не было видно. -- lav in devel@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Alexey Shabalin wrote:
> есть же kernel policy.
>
Где берется?
[-- Attachment #1: Type: text/plain, Size: 394 bytes --] On Tue, Nov 08, 2005 at 05:57:30PM +0200, Artem wrote: > Где берется? В kernel-build-tools -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): Правильно, это (невозможность запустить что-либо завёрнутое в consolehelper от рута) какая-то сложно-понимаемая особенность consolehelper, а точнее pam. С этим будем отдельно и долго разбираться. -- inger in sisyphus@ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Andrey Rahmatullin wrote:
> On Tue, Nov 08, 2005 at 03:38:47PM +0200, Artem wrote:
>
>>Кхм... Извините, что вмешиваюсь. Ведь для сборки модулей ядра 2.6
>>необходимы не только заголовки
>
> Которые kernel-headers
>
>
>>, но и сама сборочная система, имеющаяся в исходниках ядра...
>
> Которая kernel-headers-modules
>
>
>>Или в Сизифе на этот счет - свои технологии?
>
> Конечно.
>
Вау! Сизиф мне все больше нравится ;-)
On Tuesday 08 November 2005 17:27, Andrey Rahmatullin wrote: > On Tue, Nov 08, 2005 at 06:14:20PM +0300, Alexey Shabalin wrote: > > т.е. редкий модуль требует для себя всех исходников ядра. > > Мне неизвестны модули, не собирающиеся с нашими > kernel-headers-modules. Мне известны. Я хотел попробовать недавно http://www.truecrypt.org Получил при сборке: ... Linux kernel (2.6.12-std26-up-alt3) source directory [/usr/src/linux]: /usr/src/linux-2.6.12-std26-up Building kernel module... /home/yura/downloads/truecrypt-4.0/Linux/Kernel/Dm-target.c:16:16: dm.h: No such file or directory ... В исходниках ядра требуемый dm.h лежит в drivers/md/dm.h, но в пакетах с заголовками его нет. kernel-headers-std26-up-2.6.12-alt3, kernel-headers-modules-std26-up-2.6.12-alt3, соответствующие моему ядру, установлены. Как в таких случаях? Все-таки kernel-feat-* делать и все ядро пересобирать? -- Best regards Yuriy Kashirin
[-- Attachment #1: Type: text/plain, Size: 933 bytes --] Yuriy Kashirin пишет: >>>т.е. редкий модуль требует для себя всех исходников ядра. >> >>Мне неизвестны модули, не собирающиеся с нашими >>kernel-headers-modules. > > > Мне известны. > > Я хотел попробовать недавно http://www.truecrypt.org > Получил при сборке: > > ... > Linux kernel (2.6.12-std26-up-alt3) source directory > [/usr/src/linux]: /usr/src/linux-2.6.12-std26-up > Building kernel module... > /home/yura/downloads/truecrypt-4.0/Linux/Kernel/Dm-target.c:16:16: > dm.h: No such file or directory > ... > > В исходниках ядра требуемый dm.h лежит в drivers/md/dm.h, но в пакетах > с заголовками его нет. > > kernel-headers-std26-up-2.6.12-alt3, > kernel-headers-modules-std26-up-2.6.12-alt3, соответствующие моему > ядру, установлены. > > Как в таких случаях? Все-таки kernel-feat-* делать и все ядро > пересобирать? Можно просто сообщить это этом... например в багзилле... [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
On Wednesday 09 November 2005 10:01, Ivan Fedorov wrote:
> Yuriy Kashirin пишет:
> >>>т.е. редкий модуль требует для себя всех исходников ядра.
> >>Мне неизвестны модули, не собирающиеся с нашими
> >>kernel-headers-modules.
> >
> > Мне известны.
> > Я хотел попробовать недавно http://www.truecrypt.org
> > ...
> Можно просто сообщить это этом... например в багзилле...
Вы правы, просто мне это не срочно, и за неимением времени на хоть и
интересные, но эксперименты, решил отложить...
Однако #8443
--
Best regards
Yuriy Kashirin
[-- Attachment #1: Type: text/plain, Size: 844 bytes --] Привет, Всем! Как или чем можно отдебажить ядро которое после загрузки ребутится? Ядро 2.6.11 с пачтами для xen. В текущий момент я собираю ядро для xen без "излишеств". Ядро 2.6.11 патченое для xen с конфигом от 2.6.12. По конфигу я прошёлся make ARCH=xen oldconfig и после включил всё что отвалилось. В текущий момент, это последняя серьёзная проблема которую надо решить что появился xen у нас. Да, и ещё вопрос. Что надо делать если что-то из ядерных модулей не собирается? Кого пинать? Ребят из xen или с kernel.org? Я думаю что ребят из xen т.к. проблемы, скорее всего, возникают после наложения их патча. Ну и на последок. Можно вернуть kernel-source-2.6.11 из orphaned? -- http://www.livejournal.com/users/icesik/7614.html http://www.livejournal.com/users/icesik/7393.html http://www.livejournal.com/users/icesik/7024.html [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
[-- Attachment #1: Type: text/plain, Size: 189 bytes --] On Mon, Nov 21, 2005 at 02:07:52AM +0200, Igor Zubkov wrote: > Ну и на последок. Можно вернуть kernel-source-2.6.11 из orphaned? А зачем? Oно же действительно orphaned. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 675 bytes --] В сообщении от Понедельник, 21-Ноя-2005 02:38 Dmitry V. Levin написал(a): > On Mon, Nov 21, 2005 at 02:07:52AM +0200, Igor Zubkov wrote: > > Ну и на последок. Можно вернуть kernel-source-2.6.11 из orphaned? > > А зачем? Oно же действительно orphaned. В том что он orphaned я не сомневаюсь. Просто желания бегать трусцой за upstream нет никакой. Последный релиз xen был под 2.6.11. Вот от него и охота отталкиватся. Пакеты для сборки ядра с xen патчами у меня уже почти готовы. Загвоздка в том что нет нужного ядра. -- http://www.livejournal.com/users/icesik/7614.html http://www.livejournal.com/users/icesik/7393.html http://www.livejournal.com/users/icesik/7024.html [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
Здравствуйте. Прошу прощения за разорванный тред. Попробуйте в grub/menu.lst title 2.6.11-xen026-up-alt0.21 kernel (hd0,6)/boot/xen-2.0.gz dom0_mem=131072 noreboot module (hd0,6)/boot/vmlinuz-2.6.11-xen026-up-alt0.21 root=/dev/hda7 ro modulenounzip (hd0,6)/boot/initrd-2.6.11-xen026-up-alt0.21.img noreboot не даст ядру перегрузиться, будет видна проблема. Скорее всего это из-за initrd. Нужно указывать moduleunzip, хотя в документации по xen стоит module. -- Alex Yustasov
[-- Attachment #1: Type: text/plain, Size: 445 bytes --] В сообщении от Понедельник, 21-Ноя-2005 13:08 Alex Yustasov написал(a): > noreboot не даст ядру перегрузиться, будет видна проблема. Спасибо, сейчас попробую. > Скорее всего это из-за initrd. Нужно указывать moduleunzip, хотя в > документации по xen стоит module. initrd я не использую. -- http://www.livejournal.com/users/icesik/7614.html http://www.livejournal.com/users/icesik/7393.html http://www.livejournal.com/users/icesik/7024.html [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
Hello all, Пытаюсь собрать ванильное ядро. При make install получаю + exec /sbin/installkernel 2.4.32 bzImage /usr/src/linux-2.4.32/System.map '' tar: ./loopfs: Cannot mkdir: No space left on device tar: Выход, отложенный по результатам предыдущих ошибок mkinitrd: Failed to copy directory tree. lilo: Fatal: open /boot/initrd.img: No such file or directory make[1]: Залишаю каталог "/usr/src/linux-2.4.32/arch/i386/boot" На корневой файловой системе есть еще 47 мб свободного места. Неужели надо больше??? Как побороть врага? -- Best regards, Sergiy mailto:gray_post@mail.ru
On Thu, Jan 05, 2006 at 07:35:59PM +0200, Sergiy Guminilovych wrote: > Hello all, > > Пытаюсь собрать ванильное ядро. При make install получаю И зачем Вам ванильное ядро? В сизифе есть 2.4 и 2.6. Почти новые. > + exec /sbin/installkernel 2.4.32 bzImage /usr/src/linux-2.4.32/System.map '' У нас installkernel кажется другой, чем хочет предыдущая строчка. > tar: ./loopfs: Cannot mkdir: No space left on device > tar: Выход, отложенный по результатам предыдущих ошибок > mkinitrd: Failed to copy directory tree. > lilo: Fatal: open /boot/initrd.img: No such file or directory > make[1]: Залишаю каталог "/usr/src/linux-2.4.32/arch/i386/boot" > На корневой файловой системе есть еще 47 мб свободного места. Неужели > надо больше??? Как побороть врага? Если сильно надо то все ручками, раскладывать /lib/modules, /boot; генерить initrd, прописывать lilo/grub. Или посмотреть на http://www.freesource.info/wiki/Altlinux/Kernels?v=xpw http://wiki.sisyphus.ru/admin/KernelBuild?v=2d8 http://wiki.sisyphus.ru/devel/KernelCVS?v=chw -- Alex Yustasov
Здравствуйте. > скорее mkinitrd... > Если сделать руками, то: > # mkinitrd initrd-2.4.32 2.4.32 > tar: ./proc: Cannot mkdir: No space left on device > tar: ./safedev: Cannot mkdir: No space left on device > tar: ./linuxrc: Wrote only 0 of 10240 bytes > tar: Выход, отложенный по результатам предыдущих ошибок > mkinitrd: Failed to copy directory tree. У Вас ядро собрано без romfs. CONFIG_ROMFS_FS Может для создания ext2 нужно больше места. И еще попробуйте mkinitrd -v -d ... > # df -h > Файловая система Разм Исп Дост Исп% смонтирована на > /dev/hda1 244M 197M 47M 81% / > /dev/hda8 19G 19G 168M 100% /home > /dev/hda6 3,0G 909M 2,1G 31% /usr > /dev/hda7 16G 7,7G 7,5G 51% /var -- Alex Yustasov
Sergiy Guminilovych wrote:
> Hello Alex,
>
> Thursday, January 5, 2006, 8:39:40 PM, you wrote:
>>
>>И зачем Вам ванильное ядро? В сизифе есть 2.4 и 2.6. Почти новые.
>
> Необходимо собрать ядро с поддержкой imq.
Слабо вижу связь между imq и сборкой ядра руками. IMHO, стоило один раз
изучить, как оформить imq в виде kernel-feat-imq и сделать свой
src.rpm ядра с необходимым набором kernel-{fix,feat} и т.д.
BTW, "ванильное" ядро тоже можно собрать из src.rpm с не меньшим успехом.
--
// AB1002-UANIC
[-- Attachment #1: Type: text/plain, Size: 561 bytes --] В сообщении от Пятница 06 января 2006 16:11 Andrei Bulava написал(a): > >>И зачем Вам ванильное ядро? В сизифе есть 2.4 и 2.6. Почти новые. > > > > Необходимо собрать ядро с поддержкой imq. > > Слабо вижу связь между imq и сборкой ядра руками. IMHO, стоило один раз > изучить, как оформить imq в виде kernel-feat-imq и сделать свой > src.rpm ядра с необходимым набором kernel-{fix,feat} и т.д. > > BTW, "ванильное" ядро тоже можно собрать из src.rpm с не меньшим успехом. Только главное не забыть kernel-fix-build что бы собралось. Да и kernel-fix-security. [-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
Hello Alex, Friday, January 6, 2006, 3:16:52 PM, you wrote: > Здравствуйте. >> скорее mkinitrd... >> Если сделать руками, то: >> # mkinitrd initrd-2.4.32 2.4.32 >> tar: ./proc: Cannot mkdir: No space left on device >> tar: ./safedev: Cannot mkdir: No space left on device >> tar: ./linuxrc: Wrote only 0 of 10240 bytes >> tar: Выход, отложенный по результатам предыдущих ошибок >> mkinitrd: Failed to copy directory tree. > У Вас ядро собрано без romfs. CONFIG_ROMFS_FS опция присутствует > Может для создания ext2 нужно больше места. Попробую на домашней машинке для корневого раздела побольше места отвести и собрать. > И еще попробуйте mkinitrd -v -d ... тоже самое # mkinitrd -d -v /boot/initrd-2.4.32 2.4.32 mkinitrd: Generating module dependencies... mkinitrd: ...done. mkinitrd: Module "ide_hostadapter" does not exist mkinitrd: Module "ide-core" does not exist mkinitrd: Module "ide-disk" does not exist mkinitrd: Module "ide-generic" does not exist mkinitrd: Module "generic" does not exist mkinitrd: Module "scsi_hostadapter" seems to be aliased to null mkinitrd: Looking for "reiserfs" module mkinitrd: Ignoring missing "reiserfs" module mkinitrd: Using modules: mkdir: создан каталог `/tmp/initrd.LVWMk31779/tree' mkdir: создан каталог `/tmp/initrd.LVWMk31779/tree/etc' mkdir: создан каталог `/tmp/initrd.LVWMk31779/tree/dev' mkdir: создан каталог `/tmp/initrd.LVWMk31779/tree/safedev' mkdir: создан каталог `/tmp/initrd.LVWMk31779/tree/loopfs' mkdir: создан каталог `/tmp/initrd.LVWMk31779/tree/sys' mkdir: создан каталог `/tmp/initrd.LVWMk31779/tree/proc' install: создание каталога `/tmp/initrd.LVWMk31779/tree/bin' `/lib/mkinitrd/busybox' -> `/tmp/initrd.LVWMk31779/tree/bin/sh' создание символьной ссылки `/tmp/initrd.LVWMk31779/tree/bin/echo' на `sh' создание символьной ссылки `/tmp/initrd.LVWMk31779/tree/bin/insmod' на `sh' создание символьной ссылки `/tmp/initrd.LVWMk31779/tree/bin/modprobe' на `sh' создание символьной ссылки `/tmp/initrd.LVWMk31779/tree/bin/mount' на `sh' создание символьной ссылки `/tmp/initrd.LVWMk31779/tree/bin/umount' на `sh' создание символьной ссылки `/tmp/initrd.LVWMk31779/tree/bin/losetup' на `sh' создание символьной ссылки `/tmp/initrd.LVWMk31779/tree/bin/test' на `sh' mkinitrd: Created /tmp/initrd.LVWMk31779/tree/dev/console device mkinitrd: Created /tmp/initrd.LVWMk31779/tree/dev/null device mkinitrd: Created /tmp/initrd.LVWMk31779/tree/dev/ram device mkinitrd: Created /tmp/initrd.LVWMk31779/tree/dev/systty device mkinitrd: Created /tmp/initrd.LVWMk31779/tree/dev/tty1 device Contents of linuxrc: #!/bin/sh EncodeDev() { echo $(( ($2 & 0xff) | ($1 << 8) | (($2 & ~0xff) << 12) )) } /bin/mount -t proc proc /proc read cmdline </proc/cmdline cmdline=" $cmdline " if test -z "${cmdline##*[ ]root=*}" ; then root="${cmdline##*[ ]root=}" root="${root%%[ ]*}" if test -z "${root##/dev/*}" ; then root="${root#/dev/}" ( read ignored read ignored while read major minor size name ignored; do if test "$name" = "$root" ; then EncodeDev $major $minor >/proc/sys/kernel/real-root-dev break fi done ) </proc/partitions fi fi /bin/umount /proc mkinitrd: Inode count: 42 mkinitrd: Image size: 84K mkdir: создан каталог `/tmp/initrd.LVWMk31779/mnt' mkinitrd: Created image file mkinitrd: Created filesystem for ramdisk mount: going to use the loop device /dev/loop0 /var/tmp/initrd.LVWMk31779/img on /var/tmp/initrd.LVWMk31779/mnt type ext2 (rw,noexec,nosuid,nodev,loop=/dev/loop0) tar: ./proc: Cannot mkdir: No space left on device tar: ./safedev: Cannot mkdir: No space left on device tar: ./linuxrc: Wrote only 0 of 10240 bytes tar: Выход, отложенный по результатам предыдущих ошибок mkinitrd: Failed to copy directory tree. -- Best regards, Sergiy mailto:gray_post@mail.ru
Sergiy Guminilovych wrote: > Hello Andrei, > > Friday, January 6, 2006, 4:11:40 PM, you wrote: >> >>BTW, "ванильное" ядро тоже можно собрать из src.rpm с не меньшим успехом. > > Как всегда все надо сделать быстро, а ще лучше позавчера :) Хотя в > будущем планирую разобраться с src.rpm... Как раз сейчас вы идёте не самым быстрым путём. Прямая дорога - она не всегда самая короткая. "Лучше день потратить, чтоб потом за пять минут долететь" (с) не мой icesik@ верно подсказал насчёт самых нужных kernel-fix-build и kernel-fix-security. В дальнейшем стартуйте от http://wiki.sisyphus.ru/admin/KernelBuild Не надо недолюбливать чёрных кошек только потому, что вы не умеете их готовить ;-) -- // AB1002-UANIC
On Fri, Jan 06, 2006 at 12:25:10PM +0200, Sergiy Guminilovych wrote: > >> + exec /sbin/installkernel 2.4.32 bzImage /usr/src/linux-2.4.32/System.map '' > > У нас installkernel кажется другой, чем хочет предыдущая строчка. > скорее mkinitrd... Или даже оба. :) > Если сделать руками, то: > # mkinitrd initrd-2.4.32 2.4.32 > tar: ./proc: Cannot mkdir: No space left on device > tar: ./safedev: Cannot mkdir: No space left on device > tar: ./linuxrc: Wrote only 0 of 10240 bytes > tar: Выход, отложенный по результатам предыдущих ошибок > mkinitrd: Failed to copy directory tree. > # df -h > Файловая система Разм Исп Дост Исп% смонтирована на > /dev/hda1 244M 197M 47M 81% / Ну. А собранное/поставленное в /lib/modules дерево модулей сколько занимает? Кстати, там бы логично использовать логику, подобную update_chrooted -- если тот же раздел, то cp -al. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
On Friday 06 January 2006 20:26, Andrei Bulava wrote:
> icesik@ верно подсказал насчёт самых нужных kernel-fix-build и
> kernel-fix-security. В дальнейшем стартуйте от
> http://wiki.sisyphus.ru/admin/KernelBuild
Что-то там не сильно до конца... Не видать инструкций по сборке
kernel-fix/kernel-feat. Завтра, похоже, начну тыкаться...
--
С уважением, Сергей
a_s_y@sama.ru
On Monday 27 March 2006 21:40, Sergey wrote:
> Не видать инструкций по сборке kernel-fix/kernel-feat.
> Завтра, похоже, начну тыкаться...
Хм документации kernel-build-tools почти хватило. Туда бы еще
пример спека для kernel-fix/kernel-feat, чтобы не изобретать.
Пока пришлось просто скачать какой-нибудь.
--
С уважением, Сергей
a_s_y@sama.ru
Здравствуйте, повлияет ли на ядро тот факт, что оно будет компилироваться последней нормальной версией gcc или одной из более ранних? я сам думаю, что повлияет, но вот каким образом? скажется ли это на стабильности? ____________________________ С уважением, системный администратор СГТУ, каф."Системотехника" AND ЗАО "Тесар-СО", Егоров Стас ICQ:270805968 mailto:rs@sstu.ru
Добрый день! Столкнулся с такой проблемой. Есть тонкий клиент на чипсете VIA VT8231. Фактически это просто небольшой компьютер (с жестким диском). Ставил из сизифа: kernel-image-std-up-2.4.32-alt1 kernel-image-std26-up-2.6.16-alt1 Доходит до загрузки init и останвливается (и на том и на другом ядре). Последний строчки: VFS: mounted root (ext2 filesystem) readonly Freeing unused kernel memory: 136k freed Executing init=/sbin/init После этого к винту никаких обращений не идет, на запросы отвечает (ввод с клавиатуры работает). Пробовал запускать с init=/bin/bash - то же самое. Пробовал компилировать ядро самостоятельно - та же проблема. Из-за чего такое может быть? Заранее спасибо -- С уважением, Avramenko Andrew R-Style. Technical support ALT Linux TEAM Volgograd Linux Users Group
Здравствуйте, подскажите как правильно в собственном загрузчике передать параметр командной строки в ядро?(точнее в физическую память на этапе загрузки ядра) ____________________________ С уважением, системный администратор СГТУ, каф."Системотехника" AND ЗАО "Тесар-СО", Егоров Стас ICQ:270805968 mailto:rs@sstu.ru
rs пишет: > Здравствуйте, > подскажите как правильно в собственном загрузчике передать параметр > командной строки в ядро?(точнее в физическую память на этапе загрузки > ядра) Описано в Documentation/i386/zero-page.txt, Documentation/i386/boot.txt в исходниках ядра. -- Чудес не бывает - бывают только глюки... Linux Registered User #387540 http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=387540
Здравствуйте, Yuri. Вы писали 14 апреля 2006 г., 0:06:12: > rs пишет: >> Здравствуйте, >> подскажите как правильно в собственном загрузчике передать параметр >> командной строки в ядро?(точнее в физическую память на этапе загрузки >> ядра) > Описано в Documentation/i386/zero-page.txt, Documentation/i386/boot.txt > в исходниках ядра. уже дошло, что в документации на ядро всё что нужно есть ____________________________ С уважением, системный администратор СГТУ, каф."Системотехника" AND ЗАО "Тесар-СО", Егоров Стас ICQ:270805968 mailto:rs@sstu.ru
Добрый день! Я хочу передать свой пакет scons Виталию Липатову. Делаю: [mutabor@nort mutabor]$ ALTLOGIN=mutabor [mutabor@nort mutabor]$ echo "scons leader lav" > $ALTLOGIN && rsync --inplace -e ssh $ALTLOGIN incoming:/incoming/notes/Sisyphus/ Через некоторое время получаю письмо от управдома: [цитата] Dear Yury Aliaev ! The initial list of commands: 1 scons leader lav The status of performance: 1 IGNORE: leader scons lav => mantainer not found [конец цитаты] Я что-то делаю не так? P.S. s/mantainer/maIntainer/, please...
Yury Aliaev scripsit: Прошу прощения, я промахнулся рассылкой :-/...
Поможиите, не дайте пропасть неучу- - имеют ли значения опции сборки компилятора GCC ../gcc/configure --enable-share --enable-thread=posix котрым впоследствии предполагается собирать ядро. Если ядро компилить GCC, собранным ../gcc/configure --disable-share --disable-thread будут ли поодерживатся shared_library и thread? Спасибо. -- С Уважением, gosha mailto:embedded@nm.ru
Собственно, звук работает, но не работает микширование, напрочь. Под Мастером, было возможно хоть как-то рулить хотя бы уровнем микрофона, теперь (Compact), и этого не получается ep 25 14:43:16 glebook kernel: i2c_adapter i2c-0: Error: command never completed Sep 25 14:43:16 glebook last message repeated 14 times Sep 25 14:43:19 glebook hotplug: Hotplug (cpu.rc) start: succeeded Sep 25 14:43:21 glebook hal.hotplug[2819]: DEVPATH is not set (subsystem pci) Sep 25 14:43:25 glebook kernel: ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 5 Sep 25 14:43:25 glebook kernel: ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKH] -> GSI 5 ( level, low) -> IRQ 5 Sep 25 14:43:27 glebook kernel: ALSA /usr/src/RPM/BUILD/kernel-source-alsa-1.0.10/pci/ali5451 /../../alsa-kernel/pci/ali5451/ali5451.c:422: ali_stimer_read: stimer is not ready. Sep 25 14:43:28 glebook kernel: ALSA /usr/src/RPM/BUILD/kernel-source-alsa-1.0.10/pci/ali5451 /../../alsa-kernel/pci/ali5451/ali5451.c:422: ali_stimer_read: stimer is not ready. Sep 25 14:43:28 glebook kernel: ALSA /usr/src/RPM/BUILD/kernel-source-alsa-1.0.10/pci/ac97/ac 97_codec.c:1934: AC'97 1 does not respond - RESET Sep 25 14:43:28 glebook kernel: ALSA /usr/src/RPM/BUILD/kernel-source-alsa-1.0.10/pci/ac97/ac 97_codec.c:1943: AC'97 1 access is not valid [0xffffffff], removing mixer. Sep 25 14:43:28 glebook kernel: ALSA /usr/src/RPM/BUILD/kernel-source-alsa-1.0.10/pci/ali5451 /../../alsa-kernel/pci/ali5451/ali5451.c:1976: ali mixer 1 creating error. Sep 25 14:43:29 glebook hotplug: Hotplug (sound.rc) start: succeeded Sep 25 14:43:31 glebook sound.dev[3098]: Restore mixer values for /class/sound/controlC0 (0) 0000:00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02) 0000:00:07.0 ISA bridge: ALi Corporation M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+] 0000:00:08.0 Modem: ALi Corporation M5457 AC'97 Modem Controller 2.6.12-std26-up-alt10 #1 Tue Feb 28 17:29:17 MSK 2006 i686 unknown unknown GNU/Linux, на wks ядре, то же самое, разве что с загрузкой процессора ситуация полегче, не столь безобраная. -- Салют, /GLeb UIN: 15341920 jabber://gleb@asd.iao.ru sip://2387245@sipnet.ru (telephony) skype://gleb_kulikov.tomsk (telephony) sip://20000204@sip.pctel.ru (telephony) netmail: 2:5005/78
Джентельмены, а виден ли свет в конце туннеля? Вряд ли нормальная ситуация, что на *незагруженной* системе 2.6.12-std26-up-alt10 #1 Tue Feb 28 17:29:17 MSK 2006 i686 unknown unknown GNU/Linux top - 22:35:12 up 1:11, 1 users, load average: 2.46, 2.52, 2.36 На ядре wks, ситуация чуть получше --- 1 с копейками (хоть музыку/кино можно послушать, на std --- абсолютно исключено!) при прочих равных, но на Мастере (Linux tsk-523-56 2.4.26-std-up-alt13 #1 Mon Nov 14 00:25:14 MSK 2005 i686 unknown unknown GNU/Linux), на том же железе 22:38:24 up 15:39, 4 users, load average: 0,26, 0,33, 0,31 97 processes: 92 sleeping, 5 running, 0 zombie, 0 stopped CPU states: 1,8% user, 1,2% system, 22,3% nice, 0,0% iowait, 74,5% idle Это при том, что запущено два x-сервера, работают 4 человека, тв тюнер вещает на второй x-сервер. Извиняюсь за "спам", но это же ни в какие ворота не лезет. Какой новый дистрибутив, какая "стабилизация", ребята, о чём вы? С *этим*, просто невозможно работать, неужели никто не обращал внимания на это дерьмо? Какой дистрибутив, как только *это* пойдёт на сервера, поднимется *такой* вой, и правильно. Ещё раз извиняюсь, но просидев пол года под Компактом с этими *жутчайшими* тормозами системы, ну, я не знаю... разные мысли в голову приходят. Кстати, никто не натыкался, как ЭТО выглядит на сервере? Довольно мощная, 3 ГГц (! тут должен стоять неопределённый артикль б...), 512 Мб ОЗУ, машина, обслуживала 5 клиентов с /home на NFS. При незагруженной сети, но сколь мало-мальской загрузке процессора на сервере происходит что? Правильно. Все клиенты стоят раком (от нескольких до десятков минут), ибо nfs недоступна. На самом сервере видим не менее чудную картину: не срабатывают семафоры и т.п., сигналы не доставляются. В частности, наблюдаем "зависание" некоторых программ, а-ля konsole. Ежу понятно, что на Мастере (или 2.4.xxx, уж не знаю, какая фраза в данном случае корректна), ничего подобного *никогда* не наблюдалось, даже на несравнимо мснее мощном железе. Ещё раз извинияюсь, но наболело. Откровенно задрало. Работать с *этим*, невозможно. Мысль о новом дистрибутиве с такими милыми свойствами, приводит в ужас. Итак, кто виноват? Мэйнстрим? Локальная сборка? Возможно ли с этим что-то сделать? В Сизифе ядра лучше? Будут ли сборки для Компакта? (ставить Сизиф на рабочие машины, ясно дело, невозможно, а на не находящихся под реальной работой --- от тестов, мало проку). PS: Интересно, что wks ядро, ведёт себя заметно лучше. Дык, в чём проблема, товарищи "ядерщики"? -- Салют, /GLeb UIN: 15341920 jabber://gleb@asd.iao.ru sip://2387245@sipnet.ru (telephony) skype://gleb_kulikov.tomsk (telephony) sip://20000204@sip.pctel.ru (telephony) netmail: 2:5005/78
[-- Attachment #1: Type: text/plain, Size: 586 bytes --] В сообщении от 26 сентября 2006 18:57 Gleb Kulikov написал(a): > а виден ли свет в конце туннеля? Вряд ли нормальная ситуация, что на > *незагруженной* системе > > 2.6.12-std26-up-alt10 #1 Tue Feb 28 17:29:17 MSK 2006 i686 unknown unknown > GNU/Linux > > top - 22:35:12 up 1:11, 1 users, load average: 2.46, 2.52, 2.36 > > На ядре wks, ситуация чуть получше --- 1 с копейками (хоть музыку/кино > можно послушать, на std --- абсолютно исключено!) Что за железо? У меня было похуже... Похоже на проблемы с acpi. Если загрузится с acpi=off помогает? -- Marilyn Manson - Coma White [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
В сообщении от Вторник 26 Сентябрь 2006 23:16 Igor Zubkov написал: > Что за железо? 1) iRU Stilo 1514 (Transmeta 5800) 2) Duron 600 (Gygabyte GA 7IXE4 (AMD 750)) 3) Athlon 1Gz (Gygabyte GA 7IXE4 (AMD 750)) 4) Athlon 64 и т.д. абсолютные цифры везде разные, поведение -- одинаковое. > > У меня было похуже... Похоже на проблемы с acpi. Если загрузится с acpi=off > помогает? нет. -- Салют, /GLeb UIN: 15341920 jabber://gleb@asd.iao.ru sip://2387245@sipnet.ru (telephony) skype://gleb_kulikov.tomsk (telephony) sip://20000204@sip.pctel.ru (telephony) netmail: 2:5005/78
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --] В сообщении от 26 сентября 2006 19:30 Gleb Kulikov написал(a): > В сообщении от Вторник 26 Сентябрь 2006 23:16 Igor Zubkov написал: > > Что за железо? > > 1) iRU Stilo 1514 (Transmeta 5800) > > 2) Duron 600 (Gygabyte GA 7IXE4 (AMD 750)) > > 3) Athlon 1Gz (Gygabyte GA 7IXE4 (AMD 750)) > > 4) Athlon 64 > > и т.д. абсолютные цифры везде разные, поведение -- одинаковое. > > > У меня было похуже... Похоже на проблемы с acpi. Если загрузится с > > acpi=off помогает? > > нет. Что-то у вас странное в консерватории творится... [icesik@iceberg ~]$ top top - 19:35:53 up 22 days, 2:36, 1 user, load average: 0.14, 0.38, 0.45 Tasks: 176 total, 1 running, 172 sleeping, 0 stopped, 3 zombie CPU: 7.6% us, 1.7% sy, 0.0% ni, 90.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 508164K total, 498724K used, 9440K free, 7540K buffers Swap: 1028120K total, 126728K used, 901392K free, 136504K cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14847 icesik 0 0 29336 23M 4000 S 2.7 4.8 12:00.31 e17 11438 icesik 0 0 5588 2300 1816 S 2.0 0.5 8:34.65 polypaudio 15210 icesik 0 0 95580 28M 18M S 2.0 5.8 4:20.29 amarokapp 14744 root 0 0 166M 25M 3968 S 1.3 5.2 11:18.40 X 15069 icesik 0 0 22544 12M 10M S 0.3 2.6 0:09.94 konsole 15196 icesik 0 0 95580 28M 18M S 0.3 5.8 2:10.80 amarokapp 15778 icesik 0 0 25756 13M 10M S 0.3 2.8 0:35.04 sim-qt 21131 icesik 17 0 1872 1024 740 R 0.3 0.2 0:00.04 top 1 root 0 0 1420 124 88 S 0.0 0.0 0:01.27 init -- Marilyn Manson - President Dead [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
В сообщении от 26 сентября 2006 22:57 Gleb Kulikov написал(a): > Джентельмены, > > а виден ли свет в конце туннеля? Вряд ли нормальная ситуация, что на > *незагруженной* системе [жестоко скипнуто] > Итак, кто виноват? Мэйнстрим? Локальная сборка? Возможно ли с этим что-то > сделать? > > В Сизифе ядра лучше? Будут ли сборки для Компакта? (ставить Сизиф на > рабочие машины, ясно дело, невозможно, а на не находящихся под реальной > работой --- от тестов, мало проку). > > PS: Интересно, что wks ядро, ведёт себя заметно лучше. Дык, в чём проблема, > товарищи "ядерщики"? +1 Присоединяюсь. Ососбенно в части неопределённого артикля б... В чём-то компакт + сизиф ведёт себя достаточно неплохо, но в целом - головная боль ещё та... Или, может быть, всё от недостатка информации? Тогда вопрос, когда же выйдут книги, где чётко и ясно будет расписано, что и где нужно подкрутить, чтобы оптимально настроить систему _под_себя_. Может быть, по дефолту включены какие-то ресурсоёмкие сервисы, которые мне "и даром не нать, и за деньги не нать"? Ядро wks работает быстрее, НО... Но после установки wks-ядра куда-то пропал звук. После отката на std-ядро звук восстановился, НО... Но жутко глючит, вплоть до того, что возникает CPU overload при проигрывании звука при старте иксов (KDE). Это как лечить? Какие логи нужно сюда запостить, чтобы ядерщики помогли разрулить ситуёвину? -- /vip
On Tue, Sep 26, 2006 at 11:30:05PM +0700, Gleb Kulikov wrote: > > Что за железо? > 1) iRU Stilo 1514 (Transmeta 5800) > 2) Duron 600 (Gygabyte GA 7IXE4 (AMD 750)) > 3) Athlon 1Gz (Gygabyte GA 7IXE4 (AMD 750)) > 4) Athlon 64 > и т.д. абсолютные цифры везде разные, поведение -- одинаковое. Я только один раз за последний год видел нечто подобное. На чём именно, совершенно не помню. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
пересобрал ядра 2.6.16.35 и 2.6.18.5 с настройками # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y # CONFIG_PARPORT_PC_FIFO is not set CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set # CONFIG_PARPORT_ELINS64CMP is not set # CONFIG_PARPORT_1284 is not set Результат одинаков: При загрузке драйвер печатает слебующие сообщения (порт и winbond superio чип w83627hf (в котором LPT) нашел и загрузился нормально): <7>frob_econtrol(ff,34): 00 -> 34 <7>frob_econtrol(e0,00): 35 -> 15 <6>parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP(,...)] <7>frob_econtrol(ff,34): 00 -> 34 <6>parport_pc_probe_port> ok. но функции cat fileneme.ext > /dev/lp0 cat fileneme.ext > /dev/parport0 cat fileneme.ext > /dev/par0 выдают сообщения об ошибке: bash: /dev/lp0: No such device or address Как победить? Спасибо. -- С Уважением, gosha
Календари карманные от 750р/100 шт. Календари квартальные от 99 руб/шт Календари перекидные (6 листов) от 199 руб/шт Календарь настенный от 15 руб/шт Календарь «домик» от 1500 руб/100 шт. В количетсве от 1 экземляра. Сроки от 1 дня. Москва. Мобильный телефон: 8 [b](985)[/b] 722-97-27 [i]приносим свои извинения, если письмо попало не по адресу.[/i] \0
Вечер добрый. Возможно у меня скоро снова появится железка с ipw2100/2200. Посему возник вопрос об обновлении этого дела в сизифе, и как следствие вопрос - как сейчас это надо делать. Я так понял что kernel-cvs замез на 2.6.16, и все новые ядра из git собираются. Собственно вопрос в том как обновить это все в git (и что бы это автоматом собралось :) -- Alexey Shabalin
On Mon, 15 Jan 2007 00:16:00 +0300
"Alexey Shabalin" <a.shabalin@gmail.com> wrote:
> Вечер добрый.
> Возможно у меня скоро снова появится железка с ipw2100/2200.
> Посему возник вопрос об обновлении этого дела в сизифе, и как
> следствие вопрос - как сейчас это надо делать.
> Я так понял что kernel-cvs замез на 2.6.16, и все новые ядра из git собираются.
> Собственно вопрос в том как обновить это все в git (и что бы это
> автоматом собралось :)
Насколько я понял, у vsu на git.alt лежат kernel-build-scripts,
в README которых уже упоминается git =).
Импортировать из CVS в git старый модуль несложно:
git-cvsimport -d anoncvs@anoncvs.altlinux.org:/cvs/kernel kernel/modules/ipw3945
--
Grigory Batalov,
ALT Linux Team
On Mon, 15 Jan 2007 20:17:57 +0300
"Alexey Shabalin" <a.shabalin@gmail.com> wrote:
> > > Возможно у меня скоро снова появится железка с ipw2100/2200.
> > > Посему возник вопрос об обновлении этого дела в сизифе, и как
> > > следствие вопрос - как сейчас это надо делать.
> > > Я так понял что kernel-cvs замез на 2.6.16, и все новые ядра из git собираются.
> > > Собственно вопрос в том как обновить это все в git (и что бы это
> > > автоматом собралось :)
> >
> > Насколько я понял, у vsu на git.alt лежат kernel-build-scripts,
> > в README которых уже упоминается git =).
> >
> > Импортировать из CVS в git старый модуль несложно:
> >
> > git-cvsimport -d anoncvs@anoncvs.altlinux.org:/cvs/kernel kernel/modules/ipw3945
>
> импортировать - это понятно.
> а как vsu узнает, сто у меня готов к сборке новый модуль?
По сообщению lakostis@ импортировать модули не надо =)
В git можно импортировать свои kernel-source-*, а модули пока что
продолжать комитить в CVS.
--
Grigory Batalov,
ALT Linux Team
http://faq.altlinux.ru/index.php?dist=0&cat=0&kwd=patch-o-matic&type=keyword&from_year=0&from_month=0&from_day=0&to_year=0&to_month=0&to_day=0&inq=1&ina=1&f=0&action=search&button=1 > Ну так заверните feat и собирайте свои рутерные ядры :) > Может, ещё кого из заинтересованных подберёте, помнится, тема > ядер именно под маршрутизатор (без сказей и альсов там всяких, > но с развесистой сетевой частью) время от времени всплывала. Может попробуем ещё раз тему реанимировать ? И сделать что-то вроде kernel-image-rtr и iptables-rtr ? А то в одного будет тоскливо... -- С уважением, Сергей a_s_y@sama.ru
Здравствуйте. Написал видеодрайвер чипа lynx3dm (framebuffer) ftp://ftp.siliconmotion.com.tw/databooks/SM722_Rev08.pdf Драйвер написан под (kernel 2.6.18) && (2.4.32) Драйвер работает ok. За исключением, что под ядром 2.4.32 при начальном переключении консолей, на чистой консолях, (где еще ничего не печаталось) все забито значком %(каждое знакоместо). Выводы printk & printf на консоль (напр ) далее перетирают эти значки и все становится ok. Также мусор очищается scroll (<cr>/<cr>/<cr>/<cr>/<cr>/<cr>/<cr>/<cr>/) Далее консоль выглядит нормально (как всегда). Но почему в первоначально консоль может вся заполняться символом % ?? Где может собака порыться? Под Ядром 2.6 такого нет. - Все ok. -- С Уваженим, gosha.
Здравствуйте! А можно попросить поддерживающих ядро сделать бэкпорт поддержки звука ALC286? Детали здесь - http://bbs.archlinux.org/viewtopic.php?pid=275445 -- С уважением, Прокопьев Евгений
On 10.10.2007 14:34:22, Eugene Prokopiev wrote: > Здравствуйте! > > А можно попросить поддерживающих ядро сделать бэкпорт поддержки звука > ALC286? Детали здесь - http://bbs.archlinux.org/viewtopic.php? > pid=275445 В текущем Сизифе этого нет. Но судя по датам данный патч присутствует в 1.0.15rcX . То есть всё, что Вам надо сделать - скачать alsa- drivers-1.0.15.rcX.tar.bz2 и kernel-modules-alsa.src.rpm Далее второму подсунуть первое (исходники) и будет у Вас alsa-1.0.15rc Это несложно, я сам это проделывал недавно. Желаю удачи. Ильдар -- Ildar Mulyukov, free SW designer/programmer/packager ========================================= email: ildar@altlinux.ru Jabber: ildar@jabber.ru ICQ: 4334029 ALT Linux Sisyphus http://www.sisyphus.ru =========================================
>То паника, то просто зависает на initramfs (и вообще что это такое - может
>кто подскажет.)
Новый lilo.conf в студию.
.config в студию
В результате сборки у Вас получилось;
/lib/modules/2.6.23.8/......
bzImage-2.6.23.8
initrd-2.6.23.8.img
bzImage-2.6.23.8 initrd-2.6.23.8.img добавлены в lilo как вариант загрузки?
--
С Уваженим,
gosha.
[-- Attachment #1: Type: text/plain, Size: 4924 bytes --] Здравствуйте! Недавно у нас повис шлюз и находящиеся на нём OVZ-контейнеры. Он пинговался, и сквозь него можно было зайти по ssh на одну машину в локальной сети. А в контейнеры и на сам шлюз не получалось. Соответствующий кусок лога: ... Jan 12 13:14:49 gate sshd[16590]: Unknown username from 203.130.198.102 Jan 12 13:14:52 gate sshd[16618]: Unknown username from 203.130.198.102 Jan 12 13:14:55 gate kernel: Unable to handle kernel NULL pointer dereference at 0000000000000010 RIP: Jan 12 13:14:55 gate kernel: [__rb_rotate_left+7/91] __rb_rotate_left+0x7/0x5b Jan 12 13:14:55 gate kernel: [<ffffffff802249a6>] __rb_rotate_left+0x7/0x5b Jan 12 13:14:55 gate kernel: PGD c3660067 PUD a4748067 PMD 0 Jan 12 13:14:55 gate kernel: Oops: 0000 [340] SMP Jan 12 13:14:55 gate kernel: CPU: 0 Jan 12 13:14:55 gate kernel: Modules linked in: ipt_ULOG ip_gre usblp simfs vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev xt_tcpudp ipt_ttl ipt_TCPMSS iptable_mangle ipt_tos ipt_REJECT af_packet ac thermal processor button ide_cd cdrom parport_pc parport floppy psmouse pcspkr sunrpc iptable_nat ip_nat iptable_filter ip_tables x_tables usbhid tg3 ohci_hcd usbcore i2c_amd756 k8temp i2c_amd8111 i2c_core hwmon amd_rng sg dm_mod ip_conntrack_pptp ip_conntrack nfnetlink rtc ext3 jbd mbcache arcmsr sata_sil libata sd_mod scsi_mod ide_disk ide_generic amd74xx generic ide_core Jan 12 13:14:55 gate kernel: Pid: 16667, comm: sshd Not tainted 2.6.18-ovz-smp-alt11 #1 Jan 12 13:14:55 gate kernel: RIP: 0060:[__rb_rotate_left+7/91] [__rb_rotate_left+7/91] __rb_rotate_left+0x7/0x5b Jan 12 13:14:55 gate kernel: RIP: 0060:[<ffffffff802249a6>] [<ffffffff802249a6>] __rb_rotate_left+0x7/0x5b Jan 12 13:14:55 gate kernel: RSP: 0068:ffff81009e111df0 EFLAGS: 00010286 Jan 12 13:14:55 gate kernel: RAX: 0000000000000000 RBX: ffff8100cfca7188 RCX: 0000000000000000 Jan 12 13:14:55 gate kernel: RDX: 0000000000000000 RSI: ffffffff8055fa00 RDI: ffff81004d5cb088 Jan 12 13:14:55 gate kernel: RBP: ffff81004d5cb088 R08: ffff81006c9e3088 R09: ffff81009e111c08 Jan 12 13:14:55 gate kernel: R10: 000000001150af17 R11: 00000000c43c0f84 R12: ffff8100cfca7188 Jan 12 13:14:55 gate kernel: R13: ffff81002df1a688 R14: ffffffff8055fa00 R15: 0000000000000021 Jan 12 13:14:55 gate kernel: FS: 00002aaaac3edb00(0000) GS:ffffffff80587000(0000) knlGS:00000000b7ebc6c0 Jan 12 13:14:55 gate kernel: CS: 0060 DS: 0000 ES: 0000 CR0: 0000000080050033 Jan 12 13:14:55 gate kernel: CR2: 0000000000000010 CR3: 00000000a4321000 CR4: 00000000000006e0 Jan 12 13:14:55 gate kernel: Process sshd (pid: 16667, veid=107, threadinfo ffff81009e110000, task ffff8100f3040c10) Jan 12 13:14:55 gate kernel: Stack: ffffffff80211282 ffff8100cfca7198 0000000000000009 ffff81002df1a680 Jan 12 13:14:55 gate kernel: ffff81002df1a680 ffff81009e111ea8 ffffffff803031a3 0000000000000000 Jan 12 13:14:55 gate kernel: 1f3f000000000000 00000065ffffffff ffffffff804bbe60 0000000000000000 Jan 12 13:14:55 gate kernel: Call Trace: Jan 12 13:14:55 gate kernel: [rb_insert_color+178/218] rb_insert_color+0xb2/0xda Jan 12 13:14:55 gate kernel: [<ffffffff80211282>] rb_insert_color+0xb2/0xda Jan 12 13:14:55 gate kernel: [key_alloc+626/750] key_alloc+0x272/0x2ee Jan 12 13:14:55 gate kernel: [<ffffffff803031a3>] key_alloc+0x272/0x2ee Jan 12 13:14:55 gate kernel: [keyring_alloc+41/94] keyring_alloc+0x29/0x5e Jan 12 13:14:55 gate kernel: [<ffffffff80304192>] keyring_alloc+0x29/0x5e Jan 12 13:14:55 gate kernel: [alloc_uid_keyring+120/166] alloc_uid_keyring+0x78/0xa6 Jan 12 13:14:55 gate kernel: [<ffffffff8030584c>] alloc_uid_keyring+0x78/0xa6 Jan 12 13:14:55 gate kernel: [alloc_uid+274/429] alloc_uid+0x112/0x1ad Jan 12 13:14:55 gate kernel: [<ffffffff8028bd9b>] alloc_uid+0x112/0x1ad Jan 12 13:14:55 gate kernel: [set_user+15/146] set_user+0xf/0x92 Jan 12 13:14:55 gate kernel: [<ffffffff8028ea22>] set_user+0xf/0x92 Jan 12 13:14:55 gate kernel: [sys_setresuid+321/544] sys_setresuid+0x141/0x220 Jan 12 13:14:55 gate kernel: [<ffffffff80290cb3>] sys_setresuid+0x141/0x220 Jan 12 13:14:55 gate kernel: [system_call+126/131] system_call+0x7e/0x83 Jan 12 13:14:55 gate kernel: [<ffffffff8025b23a>] system_call+0x7e/0x83 Jan 12 13:14:55 gate kernel: DWARF2 unwinder stuck at system_call+0x7e/0x83 Jan 12 13:14:55 gate kernel: Leftover inexact backtrace: Jan 12 13:14:55 gate kernel: Jan 12 13:14:55 gate kernel: Jan 12 13:14:55 gate kernel: Code: 48 8b 51 10 49 83 e0 fc 48 85 d2 48 89 57 08 74 0c 48 8b 02 Jan 12 13:14:55 gate kernel: RIP [__rb_rotate_left+7/91] __rb_rotate_left+0x7/0x5b Jan 12 13:14:55 gate kernel: RIP [<ffffffff802249a6>] __rb_rotate_left+0x7/0x5b Jan 12 13:14:55 gate kernel: RSP <ffff81009e111df0> Jan 12 13:14:55 gate kernel: CR2: 0000000000000010 Jan 14 15:24:02 gate syslogd 1.4.1: restart. ... Ядро 2.6.18-ovz-smp-alt11 x86_64 -- Grigory Batalov, ALT Linux Team [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --] On Fri, Jan 18, 2008 at 10:28:50PM +0300, Grigory Batalov wrote: > Jan 12 13:14:55 gate kernel: RIP: 0060:[<ffffffff802249a6>] [<ffffffff802249a6>] __rb_rotate_left+0x7/0x5b > Jan 12 13:14:55 gate kernel: Call Trace: > Jan 12 13:14:55 gate kernel: [<ffffffff80211282>] rb_insert_color+0xb2/0xda > Jan 12 13:14:55 gate kernel: [<ffffffff803031a3>] key_alloc+0x272/0x2ee > Jan 12 13:14:55 gate kernel: [<ffffffff80304192>] keyring_alloc+0x29/0x5e > Jan 12 13:14:55 gate kernel: [<ffffffff8030584c>] alloc_uid_keyring+0x78/0xa6 > Jan 12 13:14:55 gate kernel: [<ffffffff8028bd9b>] alloc_uid+0x112/0x1ad > Jan 12 13:14:55 gate kernel: [<ffffffff8028ea22>] set_user+0xf/0x92 > Jan 12 13:14:55 gate kernel: [<ffffffff80290cb3>] sys_setresuid+0x141/0x220 > Jan 12 13:14:55 gate kernel: [<ffffffff8025b23a>] system_call+0x7e/0x83 > Ядро 2.6.18-ovz-smp-alt11 x86_64 http://bugzilla.kernel.org/show_bug.cgi?id=7727, оно же CVE-2007-0006; исправлено в kernel-image-ovz-smp-2.6.18-alt13 и kernel-image-std-smp-2.6.18-alt5. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --] On Fri, 18 Jan 2008 23:03:41 +0300, Sergey Vlasov wrote: > > Jan 12 13:14:55 gate kernel: RIP: 0060:[<ffffffff802249a6>] [<ffffffff802249a6>] __rb_rotate_left+0x7/0x5b > > > Jan 12 13:14:55 gate kernel: Call Trace: > > Jan 12 13:14:55 gate kernel: [<ffffffff80211282>] rb_insert_color+0xb2/0xda > > Jan 12 13:14:55 gate kernel: [<ffffffff803031a3>] key_alloc+0x272/0x2ee > > Jan 12 13:14:55 gate kernel: [<ffffffff80304192>] keyring_alloc+0x29/0x5e > > Jan 12 13:14:55 gate kernel: [<ffffffff8030584c>] alloc_uid_keyring+0x78/0xa6 > > Jan 12 13:14:55 gate kernel: [<ffffffff8028bd9b>] alloc_uid+0x112/0x1ad > > Jan 12 13:14:55 gate kernel: [<ffffffff8028ea22>] set_user+0xf/0x92 > > Jan 12 13:14:55 gate kernel: [<ffffffff80290cb3>] sys_setresuid+0x141/0x220 > > Jan 12 13:14:55 gate kernel: [<ffffffff8025b23a>] system_call+0x7e/0x83 > > > Ядро 2.6.18-ovz-smp-alt11 x86_64 > > http://bugzilla.kernel.org/show_bug.cgi?id=7727, оно же CVE-2007-0006; > исправлено в kernel-image-ovz-smp-2.6.18-alt13 и > kernel-image-std-smp-2.6.18-alt5. Спасибо, обновлюсь. Надо было самому следить за ядрами =). -- Grigory Batalov, ALT Linux Team [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Народ, а где-нибудь написано, как сейчас устроена ядерная разработка, где брать гиты с тем, что вливается в сизиф, и где, чёрт возьми, glibc-kernheaders.git? -- Regards, Wartan.
On Thu, Jun 26, 2008 at 02:49:17PM +0400, Wartan Hachaturow wrote: > Народ, а где-нибудь написано, как сейчас устроена ядерная > разработка http://wiki.sisyphus.ru/devel/kernelnotes -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
On 26.06.2008 16:49:17, Wartan Hachaturow wrote: > Народ, а где-нибудь написано, как сейчас устроена ядерная разработка, > где брать гиты с тем, что вливается в сизиф, и где, чёрт возьми, > glibc-kernheaders.git? rpm -q --lastchange kernel-image-std-def | head -1 * Пнд Июн 16 2008 Michail Yakushin <silicium@altlinux.ru> 2.6.25-alt3 git в http://git.altlinux.org/people/silicium/packages/?p=kernel-image-2.6.25.git;a=shortlog;h=kernel-image-std-def На счёт второго, видимо, надо спросить kas@ -- Ildar Mulyukov, free SW designer/programmer/packager ========================================= email: ildar@altlinux.ru Jabber: ildar@jabber.ru ICQ: 4334029 ALT Linux Sisyphus http://www.sisyphus.ru =========================================
[-- Attachment #1: Type: text/plain, Size: 528 bytes --] On Thu, Jun 26, 2008 at 02:49:17PM +0400, Wartan Hachaturow wrote: > Народ, а где-нибудь написано, как сейчас устроена ядерная разработка, > где брать гиты с тем, что вливается в сизиф, и где, чёрт возьми, > glibc-kernheaders.git? git://git.altlinux.org/people/kas/packages/kernel.git бранч glibc-kernheaders -- Regards, Kirill A. Shutemov + Belarus, Minsk + ALT Linux Team, http://www.altlinux.com/ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 197 bytes --]
Hi Ildar!
Thursday 26, at 05:30:29 PM you wrote:
> On 26.06.2008 16:49:17, Wartan Hachaturow wrote:
> > Народ, а где-нибудь написано, как сейчас устроена ядерная разработка,
> > где брать гиты с тем, что вливается в сизиф, и где, чёрт возьми,
> > glibc-kernheaders.git?
>
> rpm -q --lastchange kernel-image-std-def | head -1
> * Пнд Июн 16 2008 Michail Yakushin <silicium@altlinux.ru> 2.6.25-alt3
>
> git в
> http://git.altlinux.org/people/silicium/packages/?p=kernel-image-2.6.25.git;a=shortlog;h=kernel-image-std-def
>
еще про оппозиционные гиты забыли.
--
WBR et al.
On Thu, Jun 26, 2008 at 03:34:57PM +0400, Konstantin A. Lepikhov wrote: > еще про оппозиционные гиты забыли. О, добавь на http://freesource.info/wiki/AltLinux/Kernels? -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
2008/6/26 Michael Shigorin <mike@osdn.org.ua>:
> On Thu, Jun 26, 2008 at 02:49:17PM +0400, Wartan Hachaturow wrote:
>> Народ, а где-нибудь написано, как сейчас устроена ядерная
>> разработка
>
> http://wiki.sisyphus.ru/devel/kernelnotes
Я не про это, а про то, чьи ядра сейчас официальные, чьи нет, и где
всё это брать.
У нас же постоянно кто-нибудь с кем-нибудь ругается по поводу длины,
размера, формы и качества пакетов и гитов, публично уходит и приходит
-- а у меня нет ни времени, ни желания в этом разбираться, читая
километры рассылок.
Хочу чтоб прямо было написано: "дистрибутивные ядра брать тут и так
будет отныне и присно и во веки веков, аминь". И всё :)
--
Regards, Wartan.
On 26.06.2008 17:34:57, Konstantin A. Lepikhov wrote: > Hi Ildar! > Thursday 26, at 05:30:29 PM you wrote: > > On 26.06.2008 16:49:17, Wartan Hachaturow wrote: >>> Народ, а где-нибудь написано, как сейчас устроена ядерная >>> разработка, где брать гиты с тем, что вливается в сизиф, и где, >>> чёрт возьми, glibc-kernheaders.git? > > rpm -q --lastchange kernel-image-std-def | head -1 > > * Пнд Июн 16 2008 Michail Yakushin <silicium@altlinux.ru> > 2.6.25-alt3 > > git в > > > http://git.altlinux.org/people/silicium/packages/?p=kernel-image-2.6.25.git;a=shortlog;h=kernel-image-std-def > > > еще про оппозиционные гиты забыли. Ах, да.. Сам не пользуюсь, поэтому забыл.Так дали бы ссылку сразу! -- Ildar Mulyukov, free SW designer/programmer/packager ========================================= email: ildar@altlinux.ru Jabber: ildar@jabber.ru ICQ: 4334029 ALT Linux Sisyphus http://www.sisyphus.ru =========================================
On Thu, Jun 26, 2008 at 04:10:05PM +0400, Wartan Hachaturow wrote: > >> Народ, а где-нибудь написано, как сейчас устроена ядерная > >> разработка > > http://wiki.sisyphus.ru/devel/kernelnotes > Я не про это, а про то, чьи ядра сейчас официальные, чьи нет, > и где всё это брать. В наблюдаемом бардаке сколь-нибудь официальным на сейчас является std-def, насколько вообще могу судить. > У нас же постоянно кто-нибудь с кем-нибудь ругается по поводу > длины, размера, формы и качества пакетов и гитов, публично > уходит и приходит -- а у меня нет ни времени, ни желания в этом > разбираться, читая километры рассылок. Аналогично, а что делать... -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
Michael Shigorin wrote: > On Thu, Jun 26, 2008 at 04:10:05PM +0400, Wartan Hachaturow wrote: >>>> Народ, а где-нибудь написано, как сейчас устроена ядерная >>>> разработка >>> http://wiki.sisyphus.ru/devel/kernelnotes >> Я не про это, а про то, чьи ядра сейчас официальные, чьи нет, >> и где всё это брать. > > В наблюдаемом бардаке сколь-нибудь официальным на сейчас является > std-def, насколько вообще могу судить. > собственно совсем официальные у нас в сизифе std-def - собственно просто ядро без извратов,(2.6.25) xen-dom0 - ядро для xen domain 0 2.6.18 xen-domU - ядро для xen domain U(от первого отличается конфигом) 2.6.18 ovz-smp - ядро с ovz 2.6.18 Эти ядра поддерживаются и обновляются. Мои же, но из за недостатка времени поддерживемые хуже std-srv отличаетсья от std-def конфигом, реально установкой таймера и preemt std-ll аналогично. >> У нас же постоянно кто-нибудь с кем-нибудь ругается по поводу >> длины, размера, формы и качества пакетов и гитов, публично >> уходит и приходит -- а у меня нет ни времени, ни желания в этом >> разбираться, читая километры рассылок. > > Аналогично, а что делать... >
На altlinux.org выложена статья по сборке пакетов с модулями для наших ядер. Конструктивная критика приветствуется. http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --] Hi Михаил! Friday 05, at 02:43:02 PM you wrote: > На altlinux.org выложена статья по сборке пакетов с модулями для наших > ядер. > Конструктивная критика приветствуется. > http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 Сразу что бросилось в глаза: 1) Теперь о релизах пакетов с модулями. Поле release заполняется так: alt<module release>.<kernel version>.<kernel release>. - это придумано не просто так, а решает определенную проблему. Например использование magic number в kernel version позволяет избежать случайного вытеснения модуля собранного с более новым kernel-source но старым template модулем собранным со старым kernel-source но новой редакцией template. Прошу это учесть, а не просто принимать как данность или придурь авторов. 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная (поскольку для понимания процесса сборки достаточно прочитать post-halloween документ про 2.6). Лучше расписать как собирать модули без использования hasher (см. старую документацию stanv@ на вики). 3) Сборка kernel-source-module - git знать совершенно необязательно :) Лучше прочитать README из kernel-build-scripts. А вот дать пример как собирать kernel-source на основе "следящего" бранча было бы здорово. 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, поскольку нехватает i386 в начале вызова команды. Опять же, забыта -m32 в случае сборки без hasher. 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними можно, только вот неясно с кем - т.е. надо расписать задачи kernel mainteiners team, чем она занимается, для чего нужна и как с ней взаимодействовать. Поскольку текущий текст вреден - он провоцирует на неправильные действия (типа создать модуль, написать в Packager: KMT и потом KMT будет за это отдуваться). 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой. Наличие истории позволяет проследить тот длинный путь проб и ошибок + заглянуть в будущее. -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Konstantin A. Lepikhov wrote: > Hi Михаил! > > Friday 05, at 02:43:02 PM you wrote: > >> На altlinux.org выложена статья по сборке пакетов с модулями для наших >> ядер. >> Конструктивная критика приветствуется. >> http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 > Сразу что бросилось в глаза: > > 1) Теперь о релизах пакетов с модулями. Поле release заполняется так: > alt<module release>.<kernel version>.<kernel release>. > > - это придумано не просто так, а решает определенную проблему. Например > использование magic number в kernel version позволяет избежать > случайного вытеснения модуля собранного с более новым kernel-source но > старым template модулем собранным со старым kernel-source но новой > редакцией template. Прошу это учесть, а не просто принимать как > данность или придурь авторов. Если не трудно, добавь пожалуйста. > 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная > (поскольку для понимания процесса сборки достаточно прочитать > post-halloween документ про 2.6). Что она может быть вредна, согласен, долго сомневался стоит ли её писать. Лучше расписать как собирать модули без > использования hasher (см. старую документацию stanv@ на вики). А там про хешер ничего не сказано. > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > собирать kernel-source на основе "следящего" бранча было бы здорово. в смысле kernel-source большой? от ядра? > 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, > поскольку нехватает i386 в начале вызова команды. В той версии buildmoudles которую я указал, setarch i586 прикручен внутрь. Это решает некоторые проблемы с некоторыми темплейтами. > Опять же, забыта -m32 в > случае сборки без hasher. не думаю что кто-то будет собирать модуль без хешера под другую архитектуру. > 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними > можно, только вот неясно с кем - т.е. надо расписать задачи kernel > mainteiners team, чем она занимается, для чего нужна и как с ней > взаимодействовать. Поскольку текущий текст вреден - он провоцирует на > неправильные действия (типа создать модуль, написать в Packager: KMT и > потом KMT будет за это отдуваться). Документировать ещё многое надо, я только начал. > 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) А что там по твоему должно быть написано? > 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой. > Наличие истории позволяет проследить тот длинный путь проб и ошибок + > заглянуть в будущее. Если не трудно, допиши.
[-- Attachment #1: Type: text/plain, Size: 3577 bytes --] Hi Михаил! Friday 05, at 03:58:37 PM you wrote: > Konstantin A. Lepikhov wrote: > > Hi Михаил! > > > > Friday 05, at 02:43:02 PM you wrote: > > > >> На altlinux.org выложена статья по сборке пакетов с модулями для наших > >> ядер. > >> Конструктивная критика приветствуется. > >> http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 > > Сразу что бросилось в глаза: > > > > 1) Теперь о релизах пакетов с модулями. Поле release заполняется так: > > alt<module release>.<kernel version>.<kernel release>. > > > > - это придумано не просто так, а решает определенную проблему. Например > > использование magic number в kernel version позволяет избежать > > случайного вытеснения модуля собранного с более новым kernel-source но > > старым template модулем собранным со старым kernel-source но новой > > редакцией template. Прошу это учесть, а не просто принимать как > > данность или придурь авторов. > Если не трудно, добавь пожалуйста. Я ничего не пишу на wiki, поскольку это ненадежный источник хранения информации. Комментировать в рассылку - могу. > > 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная > > (поскольку для понимания процесса сборки достаточно прочитать > > post-halloween документ про 2.6). > Что она может быть вредна, согласен, долго сомневался стоит ли её писать. > Лучше расписать как собирать модули без > > использования hasher (см. старую документацию stanv@ на вики). > А там про хешер ничего не сказано. ./buildmodules --hasher это разве не хешер? > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > собирать kernel-source на основе "следящего" бранча было бы здорово. > в смысле kernel-source большой? от ядра? Нет. Когда есть branch upstream, и бранч kernel-source. См. пример kernel-image или http://git.altlinux.org/people/lakostis/packages/?p=kernel-source-et131x.git;a=summary > > 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, > > поскольку нехватает i386 в начале вызова команды. > В той версии buildmoudles которую я указал, setarch i586 прикручен > внутрь. Это решает некоторые проблемы с некоторыми темплейтами. Почему это изменение нигде не анонсировано? Более того, об этом даже не упомянуто в документации. > > Опять же, забыта -m32 в > > случае сборки без hasher. > не думаю что кто-то будет собирать модуль без хешера под другую архитектуру. а ты подумай ;) > > 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними > > можно, только вот неясно с кем - т.е. надо расписать задачи kernel > > mainteiners team, чем она занимается, для чего нужна и как с ней > > взаимодействовать. Поскольку текущий текст вреден - он провоцирует на > > неправильные действия (типа создать модуль, написать в Packager: KMT и > > потом KMT будет за это отдуваться). > Документировать ещё многое надо, я только начал. > > 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) > А что там по твоему должно быть написано? как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за уважения к чужой работе. > > 7) Отсутствует история по сборке модуей, т.е. как мы дошли до жизни такой. > > Наличие истории позволяет проследить тот длинный путь проб и ошибок + > > заглянуть в будущее. > Если не трудно, допиши. За меня это прекрасно расскажут архивы devel-kernel@. -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 435 bytes --] On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > собирать kernel-source на основе "следящего" бранча было бы здорово. Пожалуйста, искорените слово kernel-build-scripts отовсюду. Есть пакет по имени kernel-build-tools, ссылаться лучше на него. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Konstantin A. Lepikhov wrote: [skip] > Я ничего не пишу на wiki, поскольку это ненадежный источник хранения > информации. Комментировать в рассылку - могу. no comments >>> 2) Как собрать модуль локально - имхо секция вообще ненужная и вредная [skip] >> А там про хешер ничего не сказано. > ./buildmodules --hasher это разве не хешер? А ты имеешь ввиду buildmodules без хешера, а зачем это нужно, ни разу не пригодилось. >>> 3) Сборка kernel-source-module - git знать совершенно необязательно :) >>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как >>> собирать kernel-source на основе "следящего" бранча было бы здорово. >> в смысле kernel-source большой? от ядра? > Нет. Когда есть branch upstream, и бранч kernel-source. См. пример > kernel-image или > http://git.altlinux.org/people/lakostis/packages/?p=kernel-source-et131x.git;a=summary а понял, да надо дописать. >>> 4) сборка модулей - пример для сборки i586 под x86_64 дан неправильно, >>> поскольку нехватает i386 в начале вызова команды. >> В той версии buildmoudles которую я указал, setarch i586 прикручен >> внутрь. Это решает некоторые проблемы с некоторыми темплейтами. > Почему это изменение нигде не анонсировано? Более того, об этом даже не > упомянуто в документации. Это изменение описано в log git. Пока нет нормального пакета( а стоит сделать) и анонсировать нечего. >>> 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними >>> можно, только вот неясно с кем - т.е. надо расписать задачи kernel >>> mainteiners team, чем она занимается, для чего нужна и как с ней >>> взаимодействовать. Поскольку текущий текст вреден - он провоцирует на >>> неправильные действия (типа создать модуль, написать в Packager: KMT и >>> потом KMT будет за это отдуваться). >> Документировать ещё многое надо, я только начал. >>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) >> А что там по твоему должно быть написано? > как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за > уважения к чужой работе. А почему не ldv? он там тоже приложил руку. kernel-build-scripts ведёт в мой git из за изменений описаных выше.
[-- Attachment #1: Type: text/plain, Size: 843 bytes --] On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote: > > > 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) > > А что там по твоему должно быть написано? > как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за > уважения к чужой работе. Не все git'ы одинаково полезны. Общее правило для составителя документации: если есть нормальный пакет с инструментарием, не надо давать ссылку на его git-репозиторий пользователям, ибо очень редко пользователь инструмента является его разработчиком (в последнем случае ему не составит труда найти этот git-репозиторий). В данном случае пользователю нужен установленный пакет kernel-build-tools, а не его git-репозиторий. Вы же не даёте ссылки на hasher.git и gear.git для обычных пользователей hasher и gear, верно? -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Dmitry V. Levin wrote:
> On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote:
>>>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :)
>>> А что там по твоему должно быть написано?
>> как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за
>> уважения к чужой работе.
>
> Не все git'ы одинаково полезны.
> Общее правило для составителя документации: если есть нормальный пакет с
> инструментарием, не надо давать ссылку на его git-репозиторий
> пользователям, ибо очень редко пользователь инструмента является его
> разработчиком (в последнем случае ему не составит труда найти этот
> git-репозиторий). В данном случае пользователю нужен установленный
> пакет kernel-build-tools, а не его git-репозиторий.
> Вы же не даёте ссылки на hasher.git и gear.git для обычных пользователей
> hasher и gear, верно?
Блин, я пропустил что есть такой пакет. Надо поправить.
[-- Attachment #1: Type: text/plain, Size: 593 bytes --] Hi Dmitry! Friday 05, at 04:18:34 PM you wrote: > On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > собирать kernel-source на основе "следящего" бранча было бы здорово. > > Пожалуйста, искорените слово kernel-build-scripts отовсюду. > Есть пакет по имени kernel-build-tools, ссылаться лучше на него. Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется добавлять. -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #1: Type: text/plain, Size: 904 bytes --] On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote: > Friday 05, at 04:18:34 PM you wrote: > > On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > > собирать kernel-source на основе "следящего" бранча было бы здорово. > > > > Пожалуйста, искорените слово kernel-build-scripts отовсюду. > > Есть пакет по имени kernel-build-tools, ссылаться лучше на него. > Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется > добавлять. kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как могло получиться, что setarch не доехал из kernel-build-scripts в kernel-build-tools? В любом случае, лучше поправить kernel-build-tools, поскольку он опакечен. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --] Hi Dmitry! Friday 05, at 04:36:25 PM you wrote: > On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote: > > Friday 05, at 04:18:34 PM you wrote: > > > On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > > > > 3) Сборка kernel-source-module - git знать совершенно необязательно :) > > > > Лучше прочитать README из kernel-build-scripts. А вот дать пример как > > > > собирать kernel-source на основе "следящего" бранча было бы здорово. > > > > > > Пожалуйста, искорените слово kernel-build-scripts отовсюду. > > > Есть пакет по имени kernel-build-tools, ссылаться лучше на него. > > Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется > > добавлять. > > kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как > могло получиться, что setarch не доехал из kernel-build-scripts в > kernel-build-tools? В любом случае, лучше поправить kernel-build-tools, > поскольку он опакечен. Насколько я понял - вызов с setarch это локальный хак который сделал silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут порыться в git'ах самостоятельно :) -- WBR et al. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --]
Konstantin A. Lepikhov wrote:
> Hi Dmitry!
>
> Friday 05, at 04:36:25 PM you wrote:
>
>> On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote:
>>> Friday 05, at 04:18:34 PM you wrote:
>>>> On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote:
>>>>> 3) Сборка kernel-source-module - git знать совершенно необязательно :)
>>>>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как
>>>>> собирать kernel-source на основе "следящего" бранча было бы здорово.
>>>> Пожалуйста, искорените слово kernel-build-scripts отовсюду.
>>>> Есть пакет по имени kernel-build-tools, ссылаться лучше на него.
>>> Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется
>>> добавлять.
>> kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как
>> могло получиться, что setarch не доехал из kernel-build-scripts в
>> kernel-build-tools? В любом случае, лучше поправить kernel-build-tools,
>> поскольку он опакечен.
> Насколько я понял - вызов с setarch это локальный хак который сделал
> silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут
> порыться в git'ах самостоятельно :)
Да, так и было, исходя из вышесказаного имеет смысл обновить
kernel-build-tools c этим хаком.
Hi Михаил! Friday 05, at 04:24:37 PM you wrote: .... > >> А там про хешер ничего не сказано. > > ./buildmodules --hasher это разве не хешер? > А ты имеешь ввиду buildmodules без хешера, а зачем это нужно, ни разу не > пригодилось. Ну вот не надо думать, что раз это не пригодилось тебе, не пригодится и другим. Этот функционал есть в kernel-build-tools и он прекрасно реализован. Еще раз, прочти документацию stanv@ и убедись, что это работает. .... > >>> 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними > >>> можно, только вот неясно с кем - т.е. надо расписать задачи kernel > >>> mainteiners team, чем она занимается, для чего нужна и как с ней > >>> взаимодействовать. Поскольку текущий текст вреден - он провоцирует на > >>> неправильные действия (типа создать модуль, написать в Packager: KMT и > >>> потом KMT будет за это отдуваться). > >> Документировать ещё многое надо, я только начал. > >>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :) > >> А что там по твоему должно быть написано? > > как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за > > уважения к чужой работе. > А почему не ldv? он там тоже приложил руку. > kernel-build-scripts ведёт в мой git из за изменений описаных выше. Нужен пример хорошого kernel-source и template. По-моему скромному мнению в /silicium/packages таких примеров нет. -- WBR et al.
[-- Attachment #1: Type: text/plain, Size: 1378 bytes --] On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote: > Konstantin A. Lepikhov wrote: > >Friday 05, at 04:36:25 PM you wrote: > >>On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote: > >>>Friday 05, at 04:18:34 PM you wrote: > >>>>On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote: > >>>>>3) Сборка kernel-source-module - git знать совершенно необязательно :) > >>>>>Лучше прочитать README из kernel-build-scripts. А вот дать пример как > >>>>>собирать kernel-source на основе "следящего" бранча было бы здорово. > >>>>Пожалуйста, искорените слово kernel-build-scripts отовсюду. > >>>>Есть пакет по имени kernel-build-tools, ссылаться лучше на него. > >>>Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется > >>>добавлять. > >>kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как > >>могло получиться, что setarch не доехал из kernel-build-scripts в > >>kernel-build-tools? В любом случае, лучше поправить kernel-build-tools, > >>поскольку он опакечен. > >Насколько я понял - вызов с setarch это локальный хак который сделал > >silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут > >порыться в git'ах самостоятельно :) > Да, так и было, исходя из вышесказаного имеет смысл обновить > kernel-build-tools c этим хаком. Действуй! -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Konstantin A. Lepikhov wrote:
[skip]
>>>>> 5) Рекомендации. Мантейнер написан неправильно :) Взаимодействовать с ними
>>>>> можно, только вот неясно с кем - т.е. надо расписать задачи kernel
>>>>> mainteiners team, чем она занимается, для чего нужна и как с ней
>>>>> взаимодействовать. Поскольку текущий текст вреден - он провоцирует на
>>>>> неправильные действия (типа создать модуль, написать в Packager: KMT и
>>>>> потом KMT будет за это отдуваться).
>>>> Документировать ещё многое надо, я только начал.
>>>>> 6) Не совсем ясны примеры - почему там везде написан packages/silicium? :)
>>>> А что там по твоему должно быть написано?
>>> как минимум kernel-build-scripts должны вести к vsu, хотя бы из-за
>>> уважения к чужой работе.
>> А почему не ldv? он там тоже приложил руку.
>> kernel-build-scripts ведёт в мой git из за изменений описаных выше.
> Нужен пример хорошого kernel-source и template. По-моему скромному мнению
> в /silicium/packages таких примеров нет.
>
Можешь привести пример хорошего, и достаточно простого темплейта?.
Dmitry V. Levin wrote:
> On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote:
>> Konstantin A. Lepikhov wrote:
>>> Friday 05, at 04:36:25 PM you wrote:
>>>> On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote:
>>>>> Friday 05, at 04:18:34 PM you wrote:
>>>>>> On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote:
>>>>>>> 3) Сборка kernel-source-module - git знать совершенно необязательно :)
>>>>>>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как
>>>>>>> собирать kernel-source на основе "следящего" бранча было бы здорово.
>>>>>> Пожалуйста, искорените слово kernel-build-scripts отовсюду.
>>>>>> Есть пакет по имени kernel-build-tools, ссылаться лучше на него.
>>>>> Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется
>>>>> добавлять.
>>>> kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как
>>>> могло получиться, что setarch не доехал из kernel-build-scripts в
>>>> kernel-build-tools? В любом случае, лучше поправить kernel-build-tools,
>>>> поскольку он опакечен.
>>> Насколько я понял - вызов с setarch это локальный хак который сделал
>>> silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут
>>> порыться в git'ах самостоятельно :)
>> Да, так и было, исходя из вышесказаного имеет смысл обновить
>> kernel-build-tools c этим хаком.
>
> Действуй!
Я там ещё скриптов парочку сделал. Например для грамотного
menuconfig\oldconfig может их ещё доложить?
[-- Attachment #1: Type: text/plain, Size: 579 bytes --] On Fri, Sep 05, 2008 at 04:56:09PM +0400, Михаил Якушин wrote: > Dmitry V. Levin wrote: > >On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote: [...] > >>Да, так и было, исходя из вышесказаного имеет смысл обновить > >>kernel-build-tools c этим хаком. > > > >Действуй! > Я там ещё скриптов парочку сделал. Например для грамотного > menuconfig\oldconfig может их ещё доложить? Сейчас у всех скриптов пакета kernel-build-tools, лежащих в /usr/bin/, есть manpage. Если решишь паковать новые скрипты, не забудь запаковать и manpage для них. -- ldv [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
Hi Михаил!
Friday 05, at 04:56:09 PM you wrote:
> Dmitry V. Levin wrote:
> > On Fri, Sep 05, 2008 at 04:42:06PM +0400, Михаил Якушин wrote:
> >> Konstantin A. Lepikhov wrote:
> >>> Friday 05, at 04:36:25 PM you wrote:
> >>>> On Fri, Sep 05, 2008 at 04:32:33PM +0400, Konstantin A. Lepikhov wrote:
> >>>>> Friday 05, at 04:18:34 PM you wrote:
> >>>>>> On Fri, Sep 05, 2008 at 03:49:46PM +0400, Konstantin A. Lepikhov wrote:
> >>>>>>> 3) Сборка kernel-source-module - git знать совершенно необязательно :)
> >>>>>>> Лучше прочитать README из kernel-build-scripts. А вот дать пример как
> >>>>>>> собирать kernel-source на основе "следящего" бранча было бы здорово.
> >>>>>> Пожалуйста, искорените слово kernel-build-scripts отовсюду.
> >>>>>> Есть пакет по имени kernel-build-tools, ссылаться лучше на него.
> >>>>> Замечательно. Только там вызова setarch нет. Поэтому i386 пока придется
> >>>>> добавлять.
> >>>> kernel-build-tools паковал мантейнер бывшего kernel-build-scripts, как
> >>>> могло получиться, что setarch не доехал из kernel-build-scripts в
> >>>> kernel-build-tools? В любом случае, лучше поправить kernel-build-tools,
> >>>> поскольку он опакечен.
> >>> Насколько я понял - вызов с setarch это локальный хак который сделал
> >>> silicium и никому об этом не сказал. Желающие проверить эту гипотезу могут
> >>> порыться в git'ах самостоятельно :)
> >> Да, так и было, исходя из вышесказаного имеет смысл обновить
> >> kernel-build-tools c этим хаком.
> >
> > Действуй!
> Я там ещё скриптов парочку сделал. Например для грамотного
> menuconfig\oldconfig может их ещё доложить?
И где эти скрипты?
--
WBR et al.
Konstantin A. Lepikhov wrote:
[skip]
>> Я там ещё скриптов парочку сделал. Например для грамотного
>> menuconfig\oldconfig может их ещё доложить?
> И где эти скрипты?
>
Пока у меня в хомнике только. Для нормального выкладывания их стоит
заметно переработать, так как там много гвоздей.
Hi Михаил!
Friday 05, at 04:53:46 PM you wrote:
> > Нужен пример хорошого kernel-source и template. По-моему скромному мнению
> > в /silicium/packages таких примеров нет.
> >
> Можешь привести пример хорошего, и достаточно простого темплейта?.
templates/atl2/sisyphus.
--
WBR et al.
On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote: > > Если не трудно, добавь пожалуйста. > Я ничего не пишу на wiki, поскольку это ненадежный источник хранения > информации. Комментировать в рассылку - могу. Достаточно надёжный, там же все ходы записываются. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/
Hi Michael!
Monday 08, at 05:49:37 PM you wrote:
> On Fri, Sep 05, 2008 at 04:12:21PM +0400, Konstantin A. Lepikhov wrote:
> > > Если не трудно, добавь пожалуйста.
> > Я ничего не пишу на wiki, поскольку это ненадежный источник хранения
> > информации. Комментировать в рассылку - могу.
>
> Достаточно надёжный, там же все ходы записываются.
С нулевым резервированием :( Нет, лучше рассылки с зеркалами на
mail-archive и gmane.
--
WBR et al.
[-- Attachment #1: Type: text/plain, Size: 558 bytes --] On Mon, Sep 08, 2008 at 07:29:44PM +0400, Konstantin A. Lepikhov wrote: > > > > Если не трудно, добавь пожалуйста. > > > Я ничего не пишу на wiki, поскольку это ненадежный источник > > > хранения информации. Комментировать в рассылку - могу. > > Достаточно надёжный, там же все ходы записываются. > С нулевым резервированием :( Нет, лучше рассылки с зеркалами на > mail-archive и gmane. Кстати, да: предоставлю место для бэкапа www.altlinux.org. -- ---- WBR, Michael Shigorin <mike@altlinux.ru> ------ Linux.Kiev http://www.linux.kiev.ua/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
Сорри, тему не ту вписал :о) -- Denis Klimov zver
Denis Klimov wrote:
> Сорри, тему не ту вписал :о)
>
Если пачи надо включать\выключать в зависимости от версии ядер\варианта
ядер\репозитария то лучше в template если эти пачи нужны всегда то в
kernel-source-module
Приветствую. Что-то со всеми новыми ядрами, какие пробовал, во-первых, сразу после загрузки, X-ы что-то делают долго, минут 5-10, а, во-вторых, падают через дней несколько. Как только гружу 2.6.18, сразу всё нормально, пока dbus не нужен... Где связь, пока не знаю, разьве что, тот самый dbus... -- С уважением, Сергей a_s_y@sama.ru
Hi Sergey!
Wednesday 22, at 06:33:00 PM you wrote:
> Приветствую.
>
> Что-то со всеми новыми ядрами, какие пробовал, во-первых, сразу после
> загрузки, X-ы что-то делают долго, минут 5-10, а, во-вторых, падают
> через дней несколько. Как только гружу 2.6.18, сразу всё нормально,
> пока dbus не нужен... Где связь, пока не знаю, разьве что, тот самый
> dbus...
С какими из новых ядер?
--
WBR et al.
On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote:
> С какими из новых ядер?
Вот с этими точно (wks не из Сизифа ;-) ):
kernel-image-ovz-smp-2.6.26-alt0.3
kernel-image-std-def-2.6.25-alt10
kernel-image-wks-smp-2.6.26-alt0.2
std-def я между alt1 и alt10 штуки 4 пробовал, то же самое.
--
С уважением, Сергей
a_s_y@sama.ru
On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote: > > пока dbus не нужен... Где связь, пока не знаю, разьве что, тот самый > > dbus... > С какими из новых ядер? Что-то я протормозил... Не привык логи Х-ов смотреть... В общем, сегодня вот (c kernel-image-ovz-smp-2.6.26-alt0.3): Oct 22 18:11:05 kernel: [200715.230398] X:5106 freeing invalid memtype 20000000-30000000 Oct 22 18:11:07 kdm[5041]: X server for display :0 terminated unexpectedly Oct 22 18:11:21 gconfd (asy-32532): SIGHUP received, reloading all databases Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0 Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readwrite:/home/asy/.gconf" to a writable configuration source at position 1 Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2 Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readonly:/var/cache/gconf/gconf.xml.defaults" to a read-only configuration source at position 3 Oct 22 18:11:21 gconfd (asy-32532): GConf server is not in use, shutting down. Oct 22 18:11:21 gconfd (asy-32532): Exiting Oct 22 18:11:22 kernel: [200732.433074] X:19638 conflicting memory types 20000000-30000000 write-combining<->uncached-minus Oct 22 18:11:22 kernel: [200732.433091] reserve_memtype failed 0x20000000-0x30000000, track write-combining, req write-combining Oct 22 18:11:23 kernel: [200733.198137] X:19638 conflicting memory types 20000000-30000000 write-combining<->uncached-minus Oct 22 18:11:23 kernel: [200733.198154] reserve_memtype failed 0x20000000-0x30000000, track write-combining, req write-combining Oct 22 18:11:23 kernel: [200733.202148] X:19676 freeing invalid memtype 20000000-30000000 Oct 22 18:11:25 kernel: [200736.119990] X:19638 freeing invalid memtype 20000000-30000000 Тут я ему Ctrl+Alt+BackSpace надавил: Oct 22 18:11:28 kdm[5041]: X server died during startup Oct 22 18:11:28 kdm[5041]: X server for display :0 cannot be started, session disabled -- С уважением, Сергей a_s_y@sama.ru
Hi Sergey!
Wednesday 22, at 07:09:24 PM you wrote:
> On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote:
>
> > > пока dbus не нужен... Где связь, пока не знаю, разьве что, тот самый
> > > dbus...
>
> > С какими из новых ядер?
>
> Что-то я протормозил... Не привык логи Х-ов смотреть... В общем, сегодня
> вот (c kernel-image-ovz-smp-2.6.26-alt0.3):
>
> Oct 22 18:11:05 kernel: [200715.230398] X:5106 freeing invalid memtype 20000000-30000000
> Oct 22 18:11:07 kdm[5041]: X server for display :0 terminated unexpectedly
> Oct 22 18:11:21 gconfd (asy-32532): SIGHUP received, reloading all databases
> Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
> Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readwrite:/home/asy/.gconf" to a writable configuration source at position 1
> Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
> Oct 22 18:11:21 gconfd (asy-32532): Resolved address "xml:readonly:/var/cache/gconf/gconf.xml.defaults" to a read-only configuration source at position 3
> Oct 22 18:11:21 gconfd (asy-32532): GConf server is not in use, shutting down.
> Oct 22 18:11:21 gconfd (asy-32532): Exiting
> Oct 22 18:11:22 kernel: [200732.433074] X:19638 conflicting memory types 20000000-30000000 write-combining<->uncached-minus
> Oct 22 18:11:22 kernel: [200732.433091] reserve_memtype failed 0x20000000-0x30000000, track write-combining, req write-combining
> Oct 22 18:11:23 kernel: [200733.198137] X:19638 conflicting memory types 20000000-30000000 write-combining<->uncached-minus
> Oct 22 18:11:23 kernel: [200733.198154] reserve_memtype failed 0x20000000-0x30000000, track write-combining, req write-combining
> Oct 22 18:11:23 kernel: [200733.202148] X:19676 freeing invalid memtype 20000000-30000000
> Oct 22 18:11:25 kernel: [200736.119990] X:19638 freeing invalid memtype 20000000-30000000
>
> Тут я ему Ctrl+Alt+BackSpace надавил:
>
> Oct 22 18:11:28 kdm[5041]: X server died during startup
> Oct 22 18:11:28 kdm[5041]: X server for display :0 cannot be started, session disabled
>
Сдох Xorg. А что в /var/log/Xorg.0.log при этом было?
PS Может это и не ядро, а новые glibc ;)
--
WBR et al.
On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote: > Сдох Xorg. Угу. Но с 2.6.18 не дохнет. А с 25/26 недели не проходит. Причём, это первый раз, когда на глазах. Обычно встречает с утра чёрным экраном. > А что в /var/log/Xorg.0.log при этом было? К сожалению, после того, две перезагрузки было, стёрлось. :-( Поздно сообразил. > PS Может это и не ядро, а новые glibc Вот, как раз, dist-upgrade сделал после падения... Теперь glibc новые. Буду ждать следующего раза, тогда всё посмотрю. Может ещё вот что существенно: Section "Device" Identifier "Intel 8xx/9xx (generic)|0" # Driver "i810" Driver "intel" EndSection i810 не использовал с 16 сентября - он там сломался, поменял на intel. -- С уважением, Сергей a_s_y@sama.ru
Hi Sergey! Wednesday 22, at 08:04:59 PM you wrote: > On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote: > > > Сдох Xorg. > > Угу. Но с 2.6.18 не дохнет. А с 25/26 недели не проходит. Причём, это > первый раз, когда на глазах. Обычно встречает с утра чёрным экраном. может быть бага в drm. Выясняется опять же, только просмотром последних сообщений в Xorg.0.log, или отключением загрузки drm. > > > А что в /var/log/Xorg.0.log при этом было? > > К сожалению, после того, две перезагрузки было, стёрлось. :-( > Поздно сообразил. > > > PS Может это и не ядро, а новые glibc > > Вот, как раз, dist-upgrade сделал после падения... Теперь glibc новые. > Буду ждать следующего раза, тогда всё посмотрю. Может ещё вот что > существенно: > > Section "Device" > Identifier "Intel 8xx/9xx (generic)|0" > # Driver "i810" > Driver "intel" > EndSection > > i810 не использовал с 16 сентября - он там сломался, поменял на intel. > -- WBR et al.
On Wed, 22 Oct 2008 20:04:59 +0500 Sergey wrote:
> Section "Device"
> Identifier "Intel 8xx/9xx (generic)|0"
> # Driver "i810"
> Driver "intel"
> EndSection
на ноуте юзал 2.6.25 c intel драйвером - валилось. Прочитал в багзиле
что скорее всего проблемы с drm в 2.6.25. обновился до 2.6.26 - все
стало стабильно.. даже модуль для wifi rtl8180 самосборный перестал
отваливаться. :о)
--
Denis Klimov
zver
>>>>> On 23 Oct 2008 at 12:11 "DK" == Denis Klimov writes:
DK> на ноуте юзал 2.6.25 c intel драйвером - валилось. Прочитал в багзиле
DK> что скорее всего проблемы с drm в 2.6.25. обновился до 2.6.26 - все
DK> стало стабильно.. даже модуль для wifi rtl8180 самосборный перестал
DK> отваливаться. :о)
А чего самосборный, мож silicium-у его уже пора мёржить в основное ядро? ;)
--
vvk
On Thu, 23 Oct 2008 15:31:08 +0600 Vladimir V. Kamarzin wrote:
> А чего самосборный, мож silicium-у его уже пора мёржить в основное ядро? ;)
Да я как то анонсировал в kernel-devel его.. справшивал про возможные
недочеты. Ни одного ответа не получил, потому и не отправил на сборку в
Сизиф.
--
Denis Klimov
zver
[-- Attachment #1: Type: text/plain, Size: 456 bytes --] Twas brillig at 16:14:28 23.10.2008 UTC+06 when zver@altlinux.org did gyre and gimble: DK> Да я как то анонсировал в kernel-devel его.. справшивал про DK> возможные недочеты. Ни одного ответа не получил, потому и не DK> отправил на сборку в Сизиф. Зачем его отдельным модулем держать вообще? -- [-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
Hi Mikhail!
Thursday 23, at 05:17:51 PM you wrote:
> Twas brillig at 16:14:28 23.10.2008 UTC+06 when zver@altlinux.org did gyre and gimble:
>
> DK> Да я как то анонсировал в kernel-devel его.. справшивал про
> DK> возможные недочеты. Ни одного ответа не получил, потому и не
> DK> отправил на сборку в Сизиф.
>
> Зачем его отдельным модулем держать вообще?
Гм, да:
cat ~/linux-image-2.6.26/drivers/net/wireless/rtl8180_dev.c
...
/*
* Linux device driver for RTL8180 / RTL8185
*
* Copyright 2007 Michael Wu <flamingice@>
* Copyright 2007 Andrea Merello <andreamrl@>
*
* Based on the r8180 driver, which is:
* Copyright 2004-2005 Andrea Merello <andreamrl@>, et al.
*
* Thanks to Realtek for their support!
*
...
Т.е. вообще о чем идет речь?
--
WBR et al.
On Thu, 23 Oct 2008 14:56:48 +0400 Konstantin A. Lepikhov wrote: > Т.е. вообще о чем идет речь? Да, я заметил, что в ядре есть модуль rtl8180.ko На 2.6.25 с моей wifi картой на ноуте не заработал. Поэтому, перебрав штук 6 разных исходников, разбросаных по инету, нашел тот которые не стабильно, но работал. Перейдя на 2.6.26 rtl8180.ko так же не заработал. Поэтому пересобрал свой - и все опять заработало, причем очень стабильно. Если сырцы, которые использовал я пойду - kernel-image - хорошо, если у других, кто использует этот драйвер ничего не отвалиться.. Кстати, есть кто его юзает? Отпишитесь о своем опыте его использования. Используемые мной сырцы тут: http://git.altlinux.org/people/zver/packages/?p=kernel-source-rtl8180.git;a=summary Качал отсюда: http://launchpadlibrarian.net/16098501/rtl8187se_linux_26.1016.0716.2008.tar.gz Спасибо за внимание :о) P.S. самосборный модуль при сборке имеет имя r8180.ko Вместе с собой пакет для работы тянет ieee80211*.ko файлы, не знаю насколько это правильно, поэтому и справшивал. -- Denis Klimov zver
On Thursday 23 October 2008, Denis Klimov wrote:
> что скорее всего проблемы с drm в 2.6.25. обновился до 2.6.26 - все
> стало стабильно..
Так последний завал у меня с 2.6.26 получился... В общем, жду следующего
раза, буду логи собирать.
--
С уважением, Сергей
a_s_y@sama.ru
On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote:
> Сдох Xorg. А что в /var/log/Xorg.0.log при этом было?
Хвост вот такой:
Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x1ffc0001 getbl_err: 0x00000000
ipeir: 0x00000000 iphdr: 0x54c00006
LP ring tail: 0x0000d538 head: 0x0000d3b4 len: 0x0001f001 start 0x00000000
eir: 0x0000 esr: 0x0000 emr: 0xffff
instdone: 0xfa41 instpm: 0x0000
memmode: 0x00000306 instps: 0x800f00d1
hwstam: 0xfffe ier: 0x0002 imr: 0x0000 iir: 0x0080
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97
Ring end
space: 130676 wanted 131064
(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xe0beb000 at 0xb7994000
(II) intel(0): [drm] Closed DRM master.
Fatal server error:
lockup
(II) UnloadModule: "mouse"
(II) UnloadModule: "kbd"
(II) AIGLX: Suspending AIGLX clients for VT switch
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x79) [0x80c2729]
1: /lib/libc.so.6 [0xb7b54f58]
2: /usr/lib/X11/modules/drivers//intel_drv.so [0xb79c9543]
3: /usr/bin/X [0x80b07aa]
4: /usr/lib/X11/modules/extensions//libglx.so [0xb7a86bc9]
5: /usr/bin/X(AbortDDX+0x79) [0x809fa39]
6: /usr/bin/X(AbortServer+0x28) [0x8124898]
7: /usr/bin/X(FatalError+0x66) [0x8124e36]
8: /usr/lib/X11/modules/drivers//intel_drv.so(I830WaitLpRing+0x1ab) [0xb79bb35b]
9: /usr/lib/X11/modules/drivers//intel_drv.so(I830Sync+0x1c2) [0xb79bb792]
10: /usr/lib/X11/modules/drivers//intel_drv.so [0xb79e35ba]
11: /usr/lib/X11/modules//libexa.so(exaWaitSync+0x63) [0xb78a7043]
12: /usr/lib/X11/modules//libexa.so(ExaDoPrepareAccess+0x7b) [0xb78a82db]
13: /usr/lib/X11/modules//libexa.so [0xb78ab61e]
14: /usr/lib/X11/modules//libexa.so [0xb78ab7cb]
15: /usr/lib/X11/modules//libexa.so(exaDoMigration+0x3f0) [0xb78ac000]
16: /usr/lib/X11/modules//libexa.so(exaPrepareAccessReg+0x60) [0xb78a83d0]
17: /usr/lib/X11/modules//libexa.so(exaPrepareAccess+0x2c) [0xb78a841c]
18: /usr/lib/X11/modules//libexa.so(exaPrepareAccessGC+0x59) [0xb78af1b9]
19: /usr/lib/X11/modules//libexa.so [0xb78a85bf]
20: /usr/bin/X [0x815a049]
21: /usr/bin/X(ValidateGC+0x25) [0x8092235]
22: /usr/bin/X(ProcPolyFillRectangle+0xae) [0x808108e]
23: /usr/bin/X(Dispatch+0x336) [0x8084096]
24: /usr/bin/X(main+0x475) [0x806aa15]
25: /lib/libc.so.6(__libc_start_main+0xdc) [0xb7b430ec]
26: /usr/bin/X(FontFileCompleteXLFD+0x239) [0x8069df1]
FatalError re-entered, aborting
Caught signal 11. Server aborting
--
С уважением, Сергей
a_s_y@sama.ru
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432110 -- С Уваженим, gosha. > Message: 10 > Date: Fri, 24 Oct 2008 11:36:23 +0500 > From: Sergey <a_s_y@sama.ru> > Subject: Re: [d-kernel] Подземный стук с новыми ядрами > To: ALT Linux kernel packages development > <devel-kernel@lists.altlinux.org> > Message-ID: <200810241136.24416.a_s_y@sama.ru> > Content-Type: text/plain; charset="koi8-r" > > On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote: > > Сдох Xorg. А что в /var/log/Xorg.0.log при этом было? > > Хвост вот такой: > > Error in I830WaitLpRing(), timeout for 2 seconds > pgetbl_ctl: 0x1ffc0001 getbl_err: 0x00000000 > ipeir: 0x00000000 iphdr: 0x54c00006 > LP ring tail: 0x0000d538 head: 0x0000d3b4 len: 0x0001f001 start 0x00000000 > eir: 0x0000 esr: 0x0000 emr: 0xffff > instdone: 0xfa41 instpm: 0x0000 > memmode: 0x00000306 instps: 0x800f00d1 > hwstam: 0xfffe ier: 0x0002 imr: 0x0000 iir: 0x0080 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring at virtual 0xa7864000 head 0xd3b4 tail 0xd538 count 97 > Ring end > space: 130676 wanted 131064 > (II) intel(0): [drm] removed 1 reserved context for kernel > (II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xe0beb000 at 0xb7994000 > (II) intel(0): [drm] Closed DRM master. > > Fatal server error: > lockup > > > (II) UnloadModule: "mouse" > (II) UnloadModule: "kbd" > (II) AIGLX: Suspending AIGLX clients for VT switch > > Backtrace: > 0: /usr/bin/X(xf86SigHandler+0x79) [0x80c2729] > 1: /lib/libc.so.6 [0xb7b54f58] > 2: /usr/lib/X11/modules/drivers//intel_drv.so [0xb79c9543] > 3: /usr/bin/X [0x80b07aa] > 4: /usr/lib/X11/modules/extensions//libglx.so [0xb7a86bc9] > 5: /usr/bin/X(AbortDDX+0x79) [0x809fa39] > 6: /usr/bin/X(AbortServer+0x28) [0x8124898] > 7: /usr/bin/X(FatalError+0x66) [0x8124e36] > 8: /usr/lib/X11/modules/drivers//intel_drv.so(I830WaitLpRing+0x1ab) > [0xb79bb35b] 9: /usr/lib/X11/modules/drivers//intel_drv.so(I830Sync+0x1c2) > [0xb79bb792] 10: /usr/lib/X11/modules/drivers//intel_drv.so [0xb79e35ba] > 11: /usr/lib/X11/modules//libexa.so(exaWaitSync+0x63) [0xb78a7043] > 12: /usr/lib/X11/modules//libexa.so(ExaDoPrepareAccess+0x7b) [0xb78a82db] > 13: /usr/lib/X11/modules//libexa.so [0xb78ab61e] > 14: /usr/lib/X11/modules//libexa.so [0xb78ab7cb] > 15: /usr/lib/X11/modules//libexa.so(exaDoMigration+0x3f0) [0xb78ac000] > 16: /usr/lib/X11/modules//libexa.so(exaPrepareAccessReg+0x60) [0xb78a83d0] > 17: /usr/lib/X11/modules//libexa.so(exaPrepareAccess+0x2c) [0xb78a841c] > 18: /usr/lib/X11/modules//libexa.so(exaPrepareAccessGC+0x59) [0xb78af1b9] > 19: /usr/lib/X11/modules//libexa.so [0xb78a85bf] > 20: /usr/bin/X [0x815a049] > 21: /usr/bin/X(ValidateGC+0x25) [0x8092235] > 22: /usr/bin/X(ProcPolyFillRectangle+0xae) [0x808108e] > 23: /usr/bin/X(Dispatch+0x336) [0x8084096] > 24: /usr/bin/X(main+0x475) [0x806aa15] > 25: /lib/libc.so.6(__libc_start_main+0xdc) [0xb7b430ec] > 26: /usr/bin/X(FontFileCompleteXLFD+0x239) [0x8069df1] > > FatalError re-entered, aborting > Caught signal 11. Server aborting
>>>>> On 24 Oct 2008 at 12:36 "S" == Sergey writes: S> On Wednesday 22 October 2008, Konstantin A. Lepikhov wrote: >> Сдох Xorg. А что в /var/log/Xorg.0.log при этом было? S> Хвост вот такой: S> Error in I830WaitLpRing(), timeout for 2 seconds Вешал https://bugzilla.altlinux.org/show_bug.cgi?id=17492 на эту тему. Откат на бранчевый xorg помог. -- vvk
On Friday 24 October 2008, Vladimir V. Kamarzin wrote:
> S> Error in I830WaitLpRing(), timeout for 2 seconds
>
> Вешал https://bugzilla.altlinux.org/show_bug.cgi?id=17492
> на эту тему.
>
> Откат на бранчевый xorg помог.
Чтобы кто-то что-то писал, с тех пор, в Багзилле, не вижу, но
падать у меня, вроде, перестало. xorg, с тех пор, обновлялся
несколько раз, после какого обновления стало нормально - не
уследил. Ядро не менял.
--
С уважением, Сергей
a_s_y@sama.ru
>>>>> On 09 Nov 2008 at 14:44 "S" == Sergey writes: >> S> Error in I830WaitLpRing(), timeout for 2 seconds >> >> Вешал https://bugzilla.altlinux.org/show_bug.cgi?id=17492 >> на эту тему. >> >> Откат на бранчевый xorg помог. S> Чтобы кто-то что-то писал, с тех пор, в Багзилле, не вижу, но S> падать у меня, вроде, перестало. xorg, с тех пор, обновлялся S> несколько раз, после какого обновления стало нормально - не S> уследил. Ядро не менял. В апстриме пачка багов на эту тему висит, но они там явно не все про одно и то же. https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=Error+in+I830WaitLpRing&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0= Вот эта https://bugs.freedesktop.org/show_bug.cgi?id=18123 - 1-в-1 как у меня. Попробую проверить на днях свежий xorg -- vvk
5 сентября 2008 г. 13:43 Михаил Якушин написал: > На altlinux.org выложена статья по сборке пакетов с модулями для наших > ядер. > Конструктивная критика приветствуется. > http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0 > Не очень понятно в пункте: http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9 "Осталось собрать пакеты через git.alt." Да и с этими templates тоже не всё ясно, почему они находятся в репозитории public? $ git remote add public git.alt:packages/kernel-modules.git $ git push --all public И почему kernel-source также в public? $ git remote add public git.alt:packages/kernel-source-module.git $ git push --all public -- С уважением, Ринат Биков.
04.02.2011 23:06, Rinat Bikov пишет:
> 5 сентября 2008 г. 13:43 Михаил Якушин написал:
>> На altlinux.org выложена статья по сборке пакетов с модулями для наших
>> ядер.
>> Конструктивная критика приветствуется.
>> http://www.altlinux.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B5%D0%B9_%D1%8F%D0%B4%D1%80%D0%B0
>>
> Не очень понятно в пункте:
> http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9
> "Осталось собрать пакеты через git.alt."
> Да и с этими templates тоже не всё ясно, почему они находятся в
> репозитории public?
> $ git remote add public git.alt:packages/kernel-modules.git
> $ git push --all public
> И почему kernel-source также в public?
> $ git remote add public git.alt:packages/kernel-source-module.git
> $ git push --all public
>
потому что у каждого репозитария public настроен на разные адреса.
в место public можно писать прямой URL к репозитарию на сервере
4 февраля 2011 г. 23:38 Michail Yakushin написал:
[...]
>> http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9
>> "Осталось собрать пакеты через git.alt."
Всё-таки в этом месте лучше бы по-подробнее.
Как я понял, стандартом де-факто здесь является локальная сборка в
hasher'e при помощи скрипта buildmodules и последующая заливка
src.rpm-пакета?
[...]
--
С уважением, Ринат Биков.
05.02.2011 02:06, Rinat Bikov пишет: > Не очень понятно в пункте: > http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9 > "Осталось собрать пакеты через git.alt." что именно непонятно? "собрать через git.alt"? это значит собрать в сизиф из gear (в противоположность srpm). > Да и с этими templates тоже не всё ясно, что именно неясно? > почему они находятся в > репозитории public? > $ git remote add public git.alt:packages/kernel-modules.git назовите по-другому, как удобней. всё равно, кроме вас, этого никто не заметит. и да, это не репозиторий называется public, а ваш локальный псевдоним для внешнего источника, который в данном случае - ваш собственный репозиторий на git.alt. обычно у нас эти псевдонимы - origin, но в случае ядер он отведён под ядро от silicium@ ;) -- REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ
05.02.2011 13:06, Rinat Bikov пишет:
> 4 февраля 2011 г. 23:38 Michail Yakushin написал:
> [...]
>>> http://www.altlinux.org/Сборка_модулей_ядра#.D0.9A.D0.B0.D0.BA_.D0.B2.D1.8B.D0.BB.D0.BE.D0.B6.D0.B8.D1.82.D1.8C_.D1.81.D0.B2.D0.BE.D0.B9_.D0.BC.D0.BE.D0.B4.D1.83.D0.BB.D1.8C_.D0.B2_.D1.80.D0.B5.D0.BF.D0.BE.D0.B7.D0.B8.D1.82.D0.BE.D1.80.D0.B8.D0.B9
>>> "Осталось собрать пакеты через git.alt."
> Всё-таки в этом месте лучше бы по-подробнее.
> Как я понял, стандартом де-факто здесь является локальная сборка в
> hasher'e при помощи скрипта buildmodules и последующая заливка
> src.rpm-пакета?
> [...]
>
Нет. Создание им же правильного бранча и тега и сборка уже его.
Здравствуйте, уважаемые! У меня возник вопрос: как в пакете правильно указать зависимость на драйвер ядра? Вот есть kernel-modules-lsadrv-std-def, он может обеспечивать kernel-modules-lsadrv, также это может обеспечивать какой-нибудь kernel-modules-lsadrv-el-smp. И как сделать так, чтобы при попытке установить пакет (к примеру, StarBoard), ставился драйвер именно для того ядра, которое сейчас используется? Просто Requires: kernel-modules-lsadrv, не прокатит? Или у нас apt достаточно умный, чтобы это взять на себя? Ещё желательно в том случае, если не установлено ядро, для которого существует драйвер, выдавать ошибку без установки этого ядра с просьбой установить при помощи update-kernel -t одно из ядер, для которых существует необходимый драйвер. :) Или написать в багзиллу запрос на сборку этого драйвера для данного ядра. :) -- С уважением, Ринат Биков.
У меня появилась мысль, что использующаяся у нас система генерации релизов внешних модулей ядра неправильная. Напомню, на всякий случай, сейчас версия-релиз выглядит примерно так: 1.33-alt1.196609.2, где: 1.33 -- версия модуля alt1 -- версия шаблона 196609 -- версия ядра 2 -- релиз ядра В результате получается, что версия шаблона является при сравнении версий более важной, чем версия ядра, что, вообще говоря, кажется неправильным, так как что-что, а версия ядра должна быть лексикографически круче.. ну ладно, не версии модуля (хотя в идеале да), но хотя бы версии шаблона. Насколько я могу судить, это приводит к невозможности скопировать ядро и часть модулей из Сизифа, а часть собрать в бранче, так как модуль окажется либо круче, чем в Сизифе, либо младше, чем в бранче. Мне кажется, что формирование релизов вида 1.33-alt196609.2.1 или даже 1.33.196609.2-alt1 (но это противоречит концепции разделения версии и релиза) было бы удобнее Хотя, конечно, возможно, я не заметил чего-то важного ;) Антон
Здравствуйте. Подскажите как обновить модуль ядра в репах при несовпадении версий ядра сизифного и из реп (в сизифе лежит обновленный модуль ядра)? Копирование не работает, для пересборки, как я понял, необходимо создать тэг и закинуть в /gears/k/kernel-modules... как это сделать не пойму или есть более простой способ? Если возможно привести пример как сделать правильно.
Hi! This patch is intended for all kernel flavours that support AltHa. Caps provide subsets of privilleges and should be covered by AltHa.
Сабж, из longterm это 5.10 и более старые. А именно: 1. 918ce05bbe52df43849a803010b4d2bcd31ea69c в стабильной ветке 2. https://lore.kernel.org/linux-staging/2023071601-uncombed-stifling-bb3a@gregkh/ Оборудование, если избегать слова "маргинальное", можно назвать культурненьким словосочетанием "очень экзотическое". Поэтому: # CONFIG_STAGING_GASKET_FRAMEWORK is not set # CONFIG_STAGING_APEX_DRIVER is not set -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net