Re: unattended-upgrades by default?
On Fri, Nov 04, 2016 at 02:36:27PM +0100, Alexandre Detiste wrote: > 2016-11-04 13:29 GMT+01:00 Roland Mas : > > Tangentially related: is there something similar for kernels? My > > monitoring setup currently compares the age of the most recent file in > > /boot with the uptime, but I feel there must be something more proper > > somewhere. > > Unattended-Upgrades can also handle this by itself, it ships a > /etc/kernel/postinst.d/unattended-upgrades > hook that create a > /var/run/reboot-required trigger; > which tell UU to reboot the computer > after updates includiong a kernel are done. (1) > > This was a bit harsh to reboot with people logged now, > so now UU can also check for active users. (2) > > (1) & (2) are disabled by default; there's also > "Unattended-Upgrade::Automatic-Reboot-Time", > for school & offices. It might be worth pointing out that the /var/run/reboot-required is always created even if u-u- is configured to not act on it. So a monitoring system and watch for this file and we may consider showing on login (e.g. via motd) that the system needs a restart if this file is present. Cheers, Michael
Re: unattended-upgrades by default?
On Fri, Nov 04, 2016 at 03:38:38PM +0800, Paul Wise wrote: > On Fri, Nov 4, 2016 at 2:47 AM, Steve McIntyre wrote: [..] > > To solve the issue and provide security updates by default, I'm > > proposing that we should switch to installing unattended-upgrades by > > default (and enabling it too) *unless* something else in the > > installation is already expected to deal with security updates. > > I think that would be acceptable once the fix for #828215 is uploaded. > Until then, enabling unattended-upgrades is a minor but guaranteed > data loss: upgraded automatically installed packages are set to > manually installed. Thanks for this reminder Paul! #828215 is fixed in git and will be part of the next upload (which should happy early next week). Cheers, Michael
Re: [RFC] Changing APT to pre-depend on ${shlibs:Depends}
On Wed, Apr 27, 2011 at 02:53:26PM +0200, Julian Andres Klode wrote:
> Hi,
>
> I hereby request comments on changing APT to pre-depend on
> ${shlibs:Depends}. The reason is simple:
>
> When we upload a new version of APT, depending on a newer
> library version (due to new symbols, whatever), and APT gets
> unpacked before the library, the system's ability to upgrade is
> broken, unless you fix it manually via calls to dpkg.
>
> APT is fairly low in the dependency chain, and the dependencies affected
> are libgcc1 and libstdc++6 (in addition to dpkg's pre-depends). As those
> are installed on most systems anyway, pre-depending on them should not
> introduce many problems.
[..]
Thanks for brining this up. I don't have a strong opinion either
way. As David pointed out already apt internally promotes itself to
"important" (rightfully so ;) and that in turn causes the ordering
code to mark it and its dependencies for immediate configuration. So
for all practical purposes inside apt its already a
pre-depends. Making this explicit will not hurt but also not gain much
(except for the dpkg -i case).
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110428154639.GA24463@localhost
Re: cdn.debian.net as a project service?
On Sun, Mar 20, 2011 at 01:35:23AM -0600, Raphael Geissert wrote: [..] > P.S. apt also provides a "mirror" method (just like http, ftp, etc) but I > consider it to be suboptimal and a poor way to tackle the problem. Why exactly do you feel this way? What problems do you see with it? I see some benefits in the mirror method like that the mirror list is cached locally (on apt-get update) so the mirror service is hit less often. Also if the central service is down apt can still use the cached local info. Plus it supports automatic retry if a mirror fails. Thanks, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110321143856.GA8521@localhost
Re: cdn.debian.net as a project service?
On Fri, Mar 11, 2011 at 10:29:08AM +0100, Stefano Zacchiroli wrote: > On Thu, Mar 10, 2011 at 08:55:47PM +0100, Michael Vogt wrote: > > One missing feature is that it needs to send along info about the > > release/arch its looking for or the returned list needs to be extended > > to include this info. But otherwise it should be good and working. > > Have I looked in the wrong places (i.e. sources.list (5) + the list of > packages matching ^apt-transport-, as hinted by the former manpage) or > this is undocumented at the moment? In that case, that's another missing > feature :), let me know if you want a bug report about that. [..] *cough* Its indeed undocumented currently. I will fix that soonish (but help with that is very welcome of course :). I did a bunch of fixes in my branch based on the feedback from Peter Palfrader (and my own testing). The client side should be in reasonable shape now (the current code is working as well, its just missing some stuff like displaying the mirror in use etc). The fixes will be part of the next apt upload. > Regarding the GSoC project, if you think it's a good idea, it would be > great to have someone volunteering as a mentor and mailing a proposal at > soc-coordination@lists.alioth.d.o, after having filled in the proposal > template [1]. I'm fine mentoting the client side, not sure that there is enough work on the client to justify a full SoC. Maybe it can be combined with the server work. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110315164223.GE24278@localhost
Re: cdn.debian.net as a project service?
On Fri, Mar 11, 2011 at 12:20:14PM +0100, Peter Palfrader wrote: > On Thu, 10 Mar 2011, Michael Vogt wrote: > > On Thu, Mar 10, 2011 at 10:22:29AM +0100, Peter Palfrader wrote: > > > On Thu, 10 Mar 2011, Lars Wirzenius wrote: > > > > What would it take to get cdn.debian.net become a service provided by > > > > the project? In other words, cdn.debian.org, instead of cdn.debian.net. > > [..] > > > I'd really like to see support for sane mirror selection in apt itself, > > > possibly with archive support (i.e. list of mirrors somewhere on > > > ftp.d.o). That would allow apt to for instance retry on a different > > > server if the first one it tried does not work for some reason, and > > > maybe even report the problem to a central mirror. > > > > There is a "mirror" method in apt since some time that is a bit of a > > combined cdn/README.mirrors approach. Its not much used and probably > > has some rough edges but should be a good starting point. > > Very nice! > > As mentioned on IRC it probably should tell me which mirror it downloads > stuff from, when it does. Yeah, this is one of the "rough edges" I mentioned. It will report the mirror it was using on failure (and for debugging the info is available with -o Debug::Acquire::mirror=true) but not otherwise (currently). > > and the server returns a list of "good" mirrors (based on something > > like geoip) for your location as a simple text list. This is done on > > apt-get update. After that it uses a selected miror of that list to do > > the actual update and for getting the packages. The list is stored > > locally in /var/lib/apt/mirrors so that a re-query is not needed for > > each download request. It supports fallback to the next mirror if > > there are problems and also reporting back issues (via a external > > helper). > > Hmm. > > It seems that fallback is broken. I made the first mirror in AT.txt > broken (see http://auto-beta.debian.org/debian/per-cc/AT.txt, or use > deb mirror://auto-beta.debian.org/debian/per-cc/AT.txt squeeze main > I guess): [..] Indeed it is, I just reproduced it and put a fix in my apt branch (and in the debian-sid branch too). Its a tiny one line fix. > > One missing feature is that it needs to send along info about the > > release/arch its looking for or the returned list needs to be extended > > to include this info. But otherwise it should be good and working. > > Yup, that'd be nice also. My preference would be for apt to send the info to the server and let the server do something about it, does that sound reasonable? I have no opinion about the format: $base-url?version=sid&arch=i386 ? $base-url/$version/$arch ? Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110311130830.GC24278@localhost
Re: cdn.debian.net as a project service?
On Fri, Mar 11, 2011 at 11:08:15AM +0800, Paul Wise wrote: > On Fri, Mar 11, 2011 at 3:55 AM, Michael Vogt wrote: > > > There is a "mirror" method in apt since some time that is a bit of a > > combined cdn/README.mirrors approach. Its not much used and probably > > has some rough edges but should be a good starting point. > > > > The idea is that you have a sources.list entry like: > > deb mirrors://mirrors.debian.org/mirror sid main > > > > and the server returns a list of "good" mirrors (based on something > > like geoip) for your location as a simple text list. This is done on > > apt-get update. After that it uses a selected miror of that list to do > > the actual update and for getting the packages. The list is stored > > locally in /var/lib/apt/mirrors so that a re-query is not needed for > > each download request. It supports fallback to the next mirror if > > there are problems and also reporting back issues (via a external > > helper). > > > > One missing feature is that it needs to send along info about the > > release/arch its looking for or the returned list needs to be extended > > to include this info. But otherwise it should be good and working. > > Looks like the main thing missing for this to work is an > implementation of the server? Yeah. There is a implementation around launchpad of the simple protocol, I don't know much about it, but cache-country-mirrors.txt is probably a good starting point in the LP source. > What is the protocol? The current implementation will just hit the http url http://mirrors.debian.org/mirror and read a list of base urls from it. Like: http://ftp.de.debian.org/debian http://ftp.tu-clausthal.de/pub/linux/debian/ As mentioned before it should be extended to either include the (release,arch) in the request or the server needs to add it to the returned data. > Maybe this would be a good gsoc project? Sounds good to me, I'm not much of a server guy but I could certainly help with improving the client side of apt. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110311083340.GB24278@localhost
Re: cdn.debian.net as a project service?
On Thu, Mar 10, 2011 at 10:22:29AM +0100, Peter Palfrader wrote: > On Thu, 10 Mar 2011, Lars Wirzenius wrote: > > What would it take to get cdn.debian.net become a service provided by > > the project? In other words, cdn.debian.org, instead of cdn.debian.net. [..] > I'd really like to see support for sane mirror selection in apt itself, > possibly with archive support (i.e. list of mirrors somewhere on > ftp.d.o). That would allow apt to for instance retry on a different > server if the first one it tried does not work for some reason, and > maybe even report the problem to a central mirror. There is a "mirror" method in apt since some time that is a bit of a combined cdn/README.mirrors approach. Its not much used and probably has some rough edges but should be a good starting point. The idea is that you have a sources.list entry like: deb mirrors://mirrors.debian.org/mirror sid main and the server returns a list of "good" mirrors (based on something like geoip) for your location as a simple text list. This is done on apt-get update. After that it uses a selected miror of that list to do the actual update and for getting the packages. The list is stored locally in /var/lib/apt/mirrors so that a re-query is not needed for each download request. It supports fallback to the next mirror if there are problems and also reporting back issues (via a external helper). One missing feature is that it needs to send along info about the release/arch its looking for or the returned list needs to be extended to include this info. But otherwise it should be good and working. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110310195547.GA24278@localhost
Re: Results of the App Installer Meeting
B1;2703;0cOn Thu, Jan 27, 2011 at 12:55:36PM +0100, David Kalnischkies wrote: > On Thu, Jan 27, 2011 at 10:26, Andreas Tille wrote: > > What I'm missing in the summary and what was probably not discussed is > > another user oriented service: ddtp.debian.net. Translating > > descriptions of packages^Wapplications is IMHO quite important to do the > > last final step to complete world domination. As I know from some > > discussion on debian-i18n list[1] DDTSS is severely broken and needs > > definitely some love. Some effort to put it under DSA control is > > somehow stalled and the technique behind needs some more love by a > > gifted and dedicated programmer. Please do not forget: Those users who > > say "I want to draw vector graphics." will say it in their mother tongue > > and we geeks to frequently forget that this is not necessarily English. > > The availability of translated descriptions is IMHO crucial for the > > success of the App-Intaller attempt. The DDTP project is quite there > > where we need to go but it needs more love. > > If I remember correctly, DDTP got a short mention and the result was: > "Wow, debian really has translations for package descriptions?!?" > Other distributions seem to have only failed (=very outdated) tries if any. Indeed, while we talked briefly about it. It got lost in all the other topcis we discussed later, but I think its indeed a import part of the whole system. Probably more something to fix at the distro level as its useful independant of the app context. > AppStream focuses on translations of the name, keywords and (short) > summary managed by upstream. We talked shortly about longer descriptions > (possibly with markdown) but this would easily blow up the currently > rather small app-data.xml similar to how the long descriptions are quiet > a big part of our Packages files currently - beside the problem: Who will > write these descriptions: Upstream is not necessarily the best author… [..] When we take this from the desktop file, there is already i18n infrastructure for this. It will get imported into the pot file and the translations are merged into the desktop file. We just need to grab it from it. The problem of blowing up the data is indeed there, especially if we add long descriptions. In the long run it may be needed that we split similar to the Translations-$lang data. But I'm not sure if we want long descriptions in the app-data.xml. Given that we have (long) package descriptions already, it may make more sense to provide translations for those. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127131106.GF2547@bod
Re: packages with hook interfaces and no documented hook policy
On Mon, Jan 17, 2011 at 08:54:12PM +0100, Bjørn Mork wrote: > Neil Williams writes: > > On Mon, 17 Jan 2011 18:43:23 +0100 > > Bjørn Mork wrote: [..] > Sorry, I still don't see what's so special about the unattended-upgrades > cron job. Couldn't e.g. logrotate just as well argue that it should be > allowed to finish its work before the machin is hibernated? Or any > program for that matter? hibernate is supposed to freeze running > processes, not wait for them to finish. [..] Sorry for comming into this a bit late, I was traveling. Let me clarify that a bit (I also added a similar response to the bugreport). The reason that it blocks the hibernation (only *if* a upgrade is running in the background while you try to hibernate) is that during a upgrade you *may* be in the middle of replacing your kernel and if you continue to hibernate your system may not boot anymore. If no upgrade is running the hook will exit immediatly. A alternative design that I prototyped is to split the upgrade into minimal chunks so that it can be interrupted at anytime that a chunk is complete. This obviously still blocks shutdown and hibernate, but for a shorter amount of time. Or a blacklist of known problematic packages could be added, the trouble with that is that it might miss something important. If you have better suggestions how to solve this problem, I'm happy to hear (and implement) them. Until then I would recomment that you run the upgrade manually so that you have control over when exactly it happens. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110121120444.GC25623@bod
Re: packages with hook interfaces and no documented hook policy
On Tue, Jan 18, 2011 at 01:08:36AM -0400, Joey Hess wrote: > Michael Biebl wrote: > > Also; You said, the hook breaks suspend/hibernate. I don't agree this is the > > case. If there is no upgrade running, the hook will exit immediately. > > If there is an upgrade running, the hook simply blocks until the upgrade has > > finished. Suspend/Hibernate is still not 100% reliable, so this is probably > > a > > safe choice. > > ... unless the system is being suspended because it is critically low on > battery, and is going to crash and lose the user's work and need a fsck > otherwise. Indeed, if there is a way for the hook know if that is the case I'm happy to add code for this situation to exit immediately. > Suspend may not be 100% reliable on all hardware or in all > circumstances, but that is not a good excuse to make it significantly > less reliable, really. Its not doing anything on suspend, just hibernate. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110121113832.GA25623@bod
Re: APT hosed, segving in libapt-pkg-libc6.9-6.so.4.8.1
On Fri, Aug 28, 2009 at 05:41:23PM +0200, Norbert Preining wrote: > On Fr, 28 Aug 2009, Michael Vogt wrote: > > the compression types should be used. I can not reproduce this > > failure, Could you please send me your sources.list and the > > architecture you are using? > > amd64, sources.list attached, but some of the repositories are local > on my disc. > > I checked that downgrading made it work again. [..] Thanks! David Kalnischkies and I were able to reproduce a crash for sources that had no Packages file. This is fixed with the 0.7.23.1 upload. Sorry for the trouble, please let me know if that fixes your issue. Cheers, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: APT hosed, segving in libapt-pkg-libc6.9-6.so.4.8.1
On Fri, Aug 28, 2009 at 03:55:26PM +0200, Norbert Preining wrote: > Today: apt0.7.23 and bang: > $ apt-get update > .. > 99% [11 Packages rred 2154496] [Waiting for headers] [Waiting for > headers]Segmentation fault (core dumped) > > > WARNING to everyone. Thanks for your warning. > Program terminated with signal 11, Segmentation fault. > #0 0x7fdea4ad8d6d in pkgAcqIndex::Failed(std::string, > pkgAcquire::MethodConfig*) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 It looks like this is releated to the new code that adds lzma support for Package file downloads and the option to configure in what order the compression types should be used. I can not reproduce this failure, Could you please send me your sources.list and the architecture you are using? Thanks, Michael > Best wishes > > Norbert > > --- > Dr. Norbert Preining Vienna University of > Technology > Debian Developer Debian TeX > Group > gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > --- > SAFFRON WALDEN (n.) > To spray the person you are talking to with half-chewed breadcrumbs or > small pieces of whitebait. > --- Douglas Adams, The Meaning of Liff > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: screenshots.debian.net
On Sun, Nov 16, 2008 at 10:12:26PM -0800, Daniel Burrows wrote: > On Sun, Nov 16, 2008 at 07:46:27PM +0100, Christoph Haas <[EMAIL PROTECTED]> > was heard to say: > > On Sonntag, 16. November 2008, Daniel Burrows wrote: > > > On Thu, Nov 13, 2008 at 10:18:26PM +0100, Christoph Haas > > <[EMAIL PROTECTED]> was heard to say: > > > > Thumbnail (<= 160x120 pixels): > > > > http://screenshots.debian.net/thumbnail/PACKAGENAME > > > > (this URL returns a dummy thumbnail if no screenshot was found) > > > > > > Just one quick question: will there eventually be support for > > > different versions to have different screenshots? Occasionally > > > there's a big difference across versions, and users might want to > > > see it. [..] > Oh, and a third question while I'm at it: what sort of bandwidth is > available for this system? I imagine that automatically fetching > thumbnails for an entire list of a few hundred packages would be poor > manners. Do you think you can handle fetching the thumbnail of each > package the user clicks on? I was pondering about this problem as well and solved it for now by adding a little button into the package description in synaptic that fetches the thumbnail when clicked. Clicking on the thumb again gives the big image. This ensures that casual browsing of the package list does not generate network traffic on s.d.n I think even that will be quite a hit to screenshots.debian.net. I imagine in the future it may make sense to have a package for this (this was suggested already IIRC) so that the download bw is spread over all the mirrors. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Thu, Aug 02, 2007 at 06:35:40PM +0200, Joey Schulze wrote: > Reinhard Tartler wrote: > > Joey Schulze <[EMAIL PROTECTED]> writes: > > > > > Shouldn't we then remove recommends entirely and turn them into > > > regular Depends? > > > > The sometime 'soft dependencies' called feature of Recommends and > > Suggests is something which makes Debian unique compared to other > > distributions. It would be sad to loose this. > > Don't we lose it already on October 1st when apt-get installs all > Recommends per default? It's ok for high-level tools like aptitude > and Synaptic to behave that way, but I'm not exactly happy for > apt-get to go that way. [..] I understand your concern, but I do not thing it will be like this. I think it will make debian better by making it more flexible. It could even lead to a *smaller* debian as some things that are currently depends could become recommends. Take for example "gksu". It a wonderful application and a lot of packages depend on it. My impression is that a lot of those depends are because gksu is used in a .desktop file to start the application. This seems to be the case for e.g. firestarter. Strictly speaking gksu is not really a depends, the package works perfectly without gksu. So it should be a recommend and powerusers can remove it (they use the terminal anyway to start stuff). I'm pretty sure there are more such examples. The current recommends situaton is bad, but as I see it we have two options: a) change policy and say recommends should really be suggests b) fix apt and go through the transition pain Letting the current situation drag on forever is not really a solution IMHO. And we have time to fix the reommends chain and to fix the tools to better distinguish between real depends and recommends (that is not ideal currently). It is possible to see what packages got installed because they were pulled in as recommends of other package. This makes use of the automatic install information. With the current apt you can run: # apt-get autoremove -o APT::AutoRemove::RecommendsImportant=false to get those packages. There is currently no easy way to get this in synaptic but that should be straightforward to implement. In summary I think that depends will not become another form of depends and people will forget about them. Just the oposite, it will be a benefit especially for the powerusers. Regular users will just ignore them. I understand that a lot of people are not happy about a change like this, but I think recommends-cleanup and improving our tools should really make debian better and there is still time to work on the remaining issues :) I guess my initial mail should have included much more details and examples to explain the rational better. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Wed, Aug 01, 2007 at 01:35:56PM -0700, Russ Allbery wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > This is not a question of removing choice. This change in apt is the > > only thing that *gives* you a choice of installing recommends via apt. > > That the solution for disabling this in your use case is not immediately > > obvious is not a reason to not adopt a reasonable default in apt. > > I think it's also particularly annoying for our two major recommended > package installation interfaces, aptitude and apt-get, to do the opposite > thing by default with this core of a feature. What a recipe for > confusion for the average user who doesn't know the history and doesn't > choose them based on their Recommends-handling behavior! We shouldn't be > substituting tool selection for configuration. Recently apt and aptitude got closer together again and share the recommends logic and the automatic depenency information now. I'm very happy about this. Daniel Burrows did a lot of great work in this area (thanks!). This should minimize one source of confusion at least :) Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation of Recommends by default on October 1st
On Wed, Aug 01, 2007 at 07:28:27PM +0200, Marco d'Itri wrote:
> On Aug 01, Michael Vogt <[EMAIL PROTECTED]> wrote:
>
> > We, the APT Development Team, will change apt to install recommended
> > packages by default on October 1st. This should give enough time to
> Why? What is the point?
The change is meant to make apt follow policy. Policy says:
Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in all but unusual installations.
apt never really followed that policy. This lead to the current
situation where recommends are used a lot when they are not really
appropriate because only aptitude and dselect enforced them.
If the majority of people feel that the policy is wrong or does not
reflect reality, then we should change policy. But I think the current
wording ("in all but unusual installations") is pretty clear.
Cheers,
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Thu, Jun 07, 2007 at 12:59:38AM +0200, Michael Vogt wrote: > I plan to do an apt 0.7.2 upload for sid this weekend. It's a big merge > of the version in debian/experimental and the version in Ubuntu. [..] I just uploaded apt, python-apt and synaptic. If binNMUs could be arranged for the remaining packages that needs a rebuild that would be most appreciated. [..] > - automatic installation of recommends like aptitude [..] This is currently turned off because of the concerns raised. its a matter of changing the default of "APT::Install-Recommends" to true. I want to turn it on by default in the near future, but with a reasonable warning time for the transition. Many thanks for all good feedback! Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Thu, Jun 07, 2007 at 09:54:16AM +0200, Raphael Hertzog wrote: > Hi, > > On Thu, 07 Jun 2007, Michael Vogt wrote: > > I plan to do an apt 0.7.2 upload for sid this weekend. It's a big merge > > of the version in debian/experimental and the version in Ubuntu. > > Big thanks and kudos for your work! Thanks a lot! > > - automatic removal of unused dependencies moved into libapt so that > > applications like synaptic, python-apt, update-manger etc directly > > benefit from it. A HUGE thanks to Daniel Burrows (one of my personal > > heros) for his work on this feature. > > Yay! That's really awesome. I wanted that for so long. :) I keep using > apt-get one way or another for example because of "apt-get build-dep" and > I missed the fact that dependencies should be marked as auto-installed Yeah! I'm quite happy about this too :) The automatic removal of unused dependencies is a long-standing feature request in synaptic and the best way to get it there was to integrate it in libapt directly. > BTW I just wish we could have a way to say that all packages installed by this > build-dep command are marked as automatic (so that they get removed in the > next upgrade, because I have stopped playing with that source package in > the mean time). This is currently not done, but implementing it should be straightforward. > > I also asked for a project on alioth for apt so that we can have a > > shared bzr repository for the current debian versions. > > I just created it. :-) Thanks! I pushed the branch to http://bzr.debian.org/apt/ and updated http://wiki.debian.org/AptDevelopment > > This way e.g. Christian Perrier can commit his very valuable i18n > > updates directly to the repository. I also hope that more people can get > > access so that the load is a bit more shared. > > Couln't you prepare a talk for Debconf where you could introduce > people to the internals of Apt? It could be helpful to recruit new > volunteers on this crucial part of our infrastructure. Unfortunately I will not make it to this years debconf :( > > term. I would also love to find a way in the future to interface with > > the aptitude dependency problem resolver (that is superiour to the one > > in libapt). > > In what way is it superior? Until now, apt-get always found a solution to > all the dist-upgrade that I gave him whereas aptitude sometimes didn't. The apt resolver is doing well most of the time, but it does not handle complex situations as good as it could be. Aptitude 0.4.x has a complete new resolver that is described in details in: http://people.debian.org/~dburrows/model.pdf More work was put into a theoretical model and it also offers nice additions like interactive review of the available solutions. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Fri, Jun 08, 2007 at 06:21:03AM -0400, Roberto C. Sánchez wrote: > On Fri, Jun 08, 2007 at 11:36:57AM +0100, Luis Matos wrote: > > Sex, 2007-06-08 às 09:58 +0200, Francesco P. Lovergine escreveu: > > > On Thu, Jun 07, 2007 at 09:24:48AM +0200, Stefano Zacchiroli wrote: > > > > On Thu, Jun 07, 2007 at 12:59:38AM +0200, Michael Vogt wrote: [..] > How is what you describe different from what cron-apt already does? Reinhard descriped the main diverce quite nicely already. unattended-upgrades comes with a default configuration that will only apply security updates (but it can be configured in any way people want) and it will do some careful checking to not upgrade packages that require manual intervention bia conffile prompts. It will also check that a security update does not bring in a new package from a non-security source, not break the cache and offer logging/mail of the changes to the administrator. It is designed to integrate nicely with update-notifier and the apt cronjob. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Wed, Jun 06, 2007 at 09:49:00PM -0400, Joey Hess wrote: > Michael Vogt wrote: > > - support for the new dpkg "Breaks" field (thanks to Ian Jackson for > > his work on this) > > Although dpkg still doesn't have Breaks support, so we still can't use > it, AFAIK.. In this case apt will be ready for it when dpkg gets it :) > > - automatic installation of recommends like aptitude > > I want to check how this will affect d-i. The Recommends tree is still > fairly hairy/unrefined and can result in a lot of crud being pulled in. > (See #388290. Though having them installed by default would certianly > add pressure to fix the bogus ones.) We can decide to disable the feature for now until the recommends tree is cleaned up or just turn it off in the install (--no-install-recommends) I personally think the only option we have is to turn it on because otherwise the sitution will not change. But we do not have to do it just now, we can set a date for this so that there is enough time. If you are curious what would be installed with recommends turned on, you can run (with the new apt or the apt in experimental): # apt-get install --install-recommends --fix-policy to find out what package pulls in what recommend, use: # apt-get install --install-recommends --fix-policy -o Debug::pkgDepCache::AutoInstall=true > Two scenarios I'm interested in: > > 1. If tasksel runs aptitude --without-recommends, will that be enough to >avoid recommends still, or will an additonal flag now be needed? Currently both would be needed, but I hope that we can fix that so that aptitude use the same internal variable as apt (APT::Install-Recommends). > 2. Will the many parts of d-i that run apt-get -y install need to >be changed to pass some sort of flag to avoid pulling in recommends? If we decide to turn it on then you will need to pass "--on-install-recommends" or set "APT::Install-Recommends=false" in a config file. Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.7 for sid
On Wed, Jun 06, 2007 at 04:44:47PM -0700, Steve Langasek wrote: > Hi Michael, Hi Steve, > On Thu, Jun 07, 2007 at 12:59:38AM +0200, Michael Vogt wrote: > > I plan to do an apt 0.7.2 upload for sid this weekend. It's a big merge > > of the version in debian/experimental and the version in Ubuntu. > > > It will break the ABI, so all packages that depend on libapt will need > > a rebuild against this version (so expect a bit of a transition until > > everything is rebuild). It should be straightfoward, I will do uploads > > for synaptic and python-apt, I hope that the other depends follow > > quickly (I will be happy to do NMUs if someone asks me about it). > > Are source changes even needed, or can most packages be binNMUed for the > transition? The packages can be binNMUed. The API does not break. To fully use translated package descriptions some source changes are required, but aptitude has them already and patches for synaptic and python-apt are already available in bzr. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
APT 0.7 for sid
Dear Friends, I plan to do an apt 0.7.2 upload for sid this weekend. It's a big merge of the version in debian/experimental and the version in Ubuntu. It will break the ABI, so all packages that depend on libapt will need a rebuild against this version (so expect a bit of a transition until everything is rebuild). It should be straightfoward, I will do uploads for synaptic and python-apt, I hope that the other depends follow quickly (I will be happy to do NMUs if someone asks me about it). The big new stuff is: - translated package descriptions (finally!) - thanks to all the people who made this possible (otavio, grisu and the ones that I forgot) - support for the new dpkg "Breaks" field (thanks to Ian Jackson for his work on this) - apt-https support (based on libcurl) - automatic removal of unused dependencies moved into libapt so that applications like synaptic, python-apt, update-manger etc directly benefit from it. A HUGE thanks to Daniel Burrows (one of my personal heros) for his work on this feature. - automatic installation of recommends like aptitude - support for unattended installing security upgrades (via the unattended-upgrades package and the apt cronjob) Plus bug fixes and translation updates. I also asked for a project on alioth for apt so that we can have a shared bzr repository for the current debian versions. This way e.g. Christian Perrier can commit his very valuable i18n updates directly to the repository. I also hope that more people can get access so that the load is a bit more shared. My day-job keeps me pretty busy so I'm not as responsive to bugs or feature requests as I would like to (my apologizes for this). I would like to move to sha256 authentication internally in the short term. I would also love to find a way in the future to interface with the aptitude dependency problem resolver (that is superiour to the one in libapt). Thanks, Michael P.S. My bzr repository is at: http://people.debian.org/~mvo/bzr/apt/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On Mon, Jul 31, 2006 at 12:47:05PM +0200, Martijn van Oosterhout wrote: > On 7/30/06, Michael Vogt <[EMAIL PROTECTED]> wrote: > As someone who has been loosely following this for a while and > translated a few descriptions, I have a few little questions/comments: > > 1. The website you provide (http://ddtp.debian.net/) is extremely > light on detail. It contains just the translations, nothing else. > Something I've wished for is a link to a site provide translations of > common technical terms, given they're not in the usual dictionaries. > If that link got included in the email it'd be great. At the moment > I'm using http://www.kde.nl/helpen/woordenlijst.html but even that's > missing some common words. Thanks for this suggestion. We are aware of the fact that the ddtp website is a bit short on details right now. I hope one of the server admins can improve it a bit. > 2. What's with the graph? It looks odd. Michael Bramer explained that there is currently a problem with the merging and that he is investigating. > 3. There's some comments further in the thread about the review > process not working, or something like that. What's up with that? The current ddtp.debian.net server is a intermediate solution that we hope to supersede with something based on a new debian-wide translation infrastrucutre (debian-i18n people, please correct me if I'm wrong here). This means that some commands are not working on ddtp.debian.net. > Other than that, I'm glad there's progress. Getting translated > descriptions is a really cool goal. I think we got a step closer, but there is still some work to be done. I'm sure the ddtp server admins will appreciate any help and I would appreciate any testing of the new apt code :) Thanks, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Translated packages descriptions progress
On Mon, Jul 31, 2006 at 02:06:26PM +0900, Charles Plessy wrote: > Le Sun, Jul 30, 2006 at 08:26:02AM +0200, Michael Vogt a écrit : > > > > 1. send a Mail to [EMAIL PROTECTED] with the subject 'GET 3 cs' > > (use cs da de eo es fi fr hu it ja nl pl pt_BR pt_PT ru sk sv_SE > > uk as langcode) > > Dear Michael, Hi Charles, > how can we get description for specific packages? There are some pages > of the debian web site, such as in the debian-med area [1], which > contain package descriptions that have therefore have already been > translated in some languages. I'm not that familiar with the ddtp server infrastructure, I was working on the apt client integration. Michael Bramer or debian-i18n will know :) Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Translated packages descriptions progress
Dear Friends, the current version of apt in debian/experimental has support for translated package descriptions and we have a the current translations available for sid on the mirrors (currently not on ftp.debian.org itself because of the mirror split I suspect). This means that everyone with non-english locales will get translated packages descriptions on the next "apt-get update" run if they install the apt from experimental. Synaptic and aptitude have support for this feature as well, python-apt and others will follow soon. Please help testing the new code and report problems and/or success. It should be enough to install apt, python-apt, synaptic from experimental and if your LANG is set to something other than C it should download the appropriate translation indexes and displays them with apt-cache or synaptic (warning: not everything is translated yet). I think this is a important step forward for a fully localized system and I'm pretty excited about it. The ddtp system was developed by Michael Bramer, the code in apt is based on the work of Otavio Salvador <[EMAIL PROTECTED]> who implemented a patch against apt for 0.5.5.1. The translated package descriptions where imported by Anthony Towns for sid. Thanks to all of you :) And to the busy translators who work on making that happen! More information: * the first announcement I was able to find: http://lwn.net/2002/0103/a/deb-ddtp.php3 * original announcement about apt-i18n: http://lwn.net/Articles/34753/ The ddtp project is hosted at http://ddtp.debian.net/. You can view the status of the various package descriptions via the webpage. If you want to help translating, please to the following: 1. send a Mail to [EMAIL PROTECTED] with the subject 'GET 3 cs' (use cs da de eo es fi fr hu it ja nl pl pt_BR pt_PT ru sk sv_SE uk as langcode) 2. you get a mail from the ddtp server with three untranslated descriptions. 3. Translate the descriptions 4. send this as mail attachments back to [EMAIL PROTECTED] Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
On Wed, May 10, 2006 at 11:05:03AM +0200, Goswin von Brederlow wrote: > Pierre Habouzit <[EMAIL PROTECTED]> writes: > > Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit : [..] > Except that apt-get fails if any of the signatures are unknown or > expired. So you still need both keys and not just one of them as you > intent. This was fixed in January IIRC. [..] > > IMHO, changing the key every year at any date is not problematic at all, > > because there is plenty of solution to do smooth replacement of the > > key. > > Do you see any drawbacks with my proposal of having Release.key next > to each Releas.gpg or do you have a better idea that will work for > every apt-getable archive? If we do this, we must make sure that Relesae.key is properly authenticated. The authentication of the debian-archive-keyring package is the same as for any other package, we have a signed Release file for it with valid md5sums. I like the general idea of this and would like to combine it with the idea of having a master-key. I think that the debian-archive-keyring solve the problem of key-rollover more or less. But it does not solve the problem of key-compromises. The archive key is then invalid and we can't sign a new debian-archive-keyring package with it. A possible solution for this problem is a master key that is only used to issue new signing keys and is otherwise stored offline/off-site (and maybe split). A "apt-key update" would download a new keyring from a fixed location (maybe next to the Release file as Goswin suggested) and check if the new keys are signed with the master key. If so, the key is considered trusted. What do the others think about this? It shouldn't be very hard to implement, we can just ship the new master public-key in the debian-archive-keyring package (or just put it straight into apt). The problem here is of course what to do if the master key is compromised :) But the trust chain has to start somewhere and the master key would only be used once a year to issue new signing keys and that will expose it much less than our current signing key. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:22:50AM +0100, Petter Reinholdtsen wrote: > [Michael Vogt] > > Sorry for the delay. I'm preparing a new upload that adds the 2006 > > archive key to the default keyring. > > Sounds good. Will this automatically take care of the key update and > make sure no manual intervention is needed to get packages upgraded? I uploaded a new apt that supports multiple signatures on the release file. The policy is that it needs at least one good signature and no bad signatures (but any number number of NO_PUBKEY signatures) to be considered trusted. It will still warn about missing keys but that's only fatal if no good signature was found. The upload also contains the new key in apts default keyring. This dosn't fix the key-upgrade problem yet. I outlined my proposal in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 Early testing (from incoming) is welcome :) > Isn't Ubuntu using the signed apt stuff? How are they handling the > new archive keys? Ubuntu handles the archive keys with the mechanism described in #345891. Threre is a "ubuntu-keyring" package that contains the valid and no-longer valid server keys. apt-key update takes care of adding/removing the appropriate keys. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Fri, Jan 06, 2006 at 01:26:41AM +0100, Bartosz Fenski aka fEnIo wrote: > On Thu, Jan 05, 2006 at 11:13:06PM +0100, Michael Vogt wrote: > > > These are all notable in > > > > > > a) being RC > > > b) not having any response from an apt maintainer > > > > Sorry for the delay. I'm preparing a new upload that adds the 2006 > > archive key to the default keyring. > > Does it mean we need new version of apt everytime when key changes? Please see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 for a proposal how the keys can be upgraded in the future. We certainly don't want new apt uploads just for that in the future. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT public key updates?
On Thu, Jan 05, 2006 at 03:02:05PM -0500, Joey Hess wrote: > Daniel Leidert wrote: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345823 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345891 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345956 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346002 > > These are all notable in > > a) being RC > b) not having any response from an apt maintainer Sorry for the delay. I'm preparing a new upload that adds the 2006 archive key to the default keyring. Cheers, Michael P.S. The source for debians apt is maintained with baz (package 'bazaar') at: http://people.debian.org/~mvo/arch/ in the [EMAIL PROTECTED]/apt--debian-sid--0 branch -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages file missing from unstable archive
On Thu, Oct 27, 2005 at 10:06:22AM +0200, Robert Lemmen wrote: > On Wed, Oct 26, 2005 at 09:15:38PM -0400, Joey Hess wrote: > > (And yes, we still need a solution to speed up the actual deb file > > downloads..) [..] > if zsync would be taught to handle .deb files as it does .gz files, and > a method for apt be written, how big are the chances that support could > be integrated into dak? the effort wouldn't be *that* big... I did a pretty unscientific test with apt and the changes from 0.6.41 -> 0.6.42.1. It contains a good mix of code changes, documentation updates and translation updates [1]. With the two normals debs I got no effect at all because no usable data was found. I then repacked the data.tar.gz and control.tar.gz inside the deb with "--rsyncable" (and reassmbled the deb). This resulted in: "Read apt_0.6.41_i386.deb. Target 0.8% complete." So this didn't had a lot of effect either. My next test was to use only the data.tar.gz of the two archives. Zsync will extract the gzip file then and use the tar as the base. With that I got: 8< Read data.tar.gz. Target 34.1% complete. used 1056768 local, fetched 938415 8< The size of the data.tar.gz is 1210514. A problem is that zsync needs to teached to deal with deb files (that is, that it needs to unpack the data.tar and use that for the syncs). Having it inside dak is not (at the beging) a requirement. Zsync seems to be able to deal with URLs, so we could create a pool with zsync files on any server and let them point to ftp.debian.org. We need to guarantee that the md5sum of the synced deb must match the md5sum in the Packages file. Initial tests indicate that that is not the case. Only the md5sum of the unpacked data.tar file matches, not from the gzip file (or the deb). This is a serious showstoper IMHO. Cheers, Michael [1] I would love to hear results from other people testing it with different packages and different changes. -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Interfaces for dpkg/deb packages
On Thu, Sep 15, 2005 at 02:40:06PM -0700, Christopher Crammond wrote: > I was curious as to where I might be able to find out what > non-command-line interfaces into .deb packages are available. For > instance, is there a C interface that could pull out information such as > Name, Version, Release, etc... ? [..] libapt_inst (from the apt package) provides a interface in C++ and python-apt (module apt_inst) provides a interface in python. Attached is a example using python-apt. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo #!/usr/bin/env python # some example for apt_inst import apt_pkg import apt_inst import sys def Callback(What,Name,Link,Mode,UID,GID,Size,MTime,Major,Minor): """ callback for debExtract """ print "%s '%s','%s',%u,%u,%u,%u,%u,%u,%u"\ % (What,Name,Link,Mode,UID,GID,Size, MTime, Major, Minor); if __name__ == "__main__": if len(sys.argv) < 2: print "need filename argumnet" sys.exit(1) file = sys.argv[1] print "Working on: %s" % file print "Displaying data.tar.gz:" apt_inst.debExtract(open(file), Callback, "data.tar.gz") print "Now extracting the control file:" control = apt_inst.debExtractControl(open(file)) sections = apt_pkg.ParseSection(control) print sections print "Maintainer is: " print sections["Maintainer"] print print "DependsOn: " depends = sections["Depends"] print apt_pkg.ParseDepends(depends)
Re: apt with index diff support
On Sun, Sep 18, 2005 at 01:33:29PM +0200, Andreas Metzler wrote: > Michael Vogt <[EMAIL PROTECTED]> wrote: [..] > The remapping features seems not to work with deb-src entries. > > > (SID)[EMAIL PROTECTED]:/tmp$ apt-get -o > APT::URL-Remap::http://merkel.debian.org/~aba/debian/=http://ftp.at.debian.org/debian/ > source efax > Reading package lists... Done > Building dependency tree... Done > Need to get 114kB of source archives. > Err http://merkel.debian.org sid/main efax 1:0.9a-15 (dsc) > 404 Not Found > [...] > Failed to fetch > http://merkel.debian.org/~aba/debian/pool/main/e/efax/efax_0.9a-15.dsc 404 > Not Found > [...] > E: Failed to fetch some archives. It's a known issue that URL-Remap only works for binary packages. It shouldn't be hard to extend it for source packages as well. But I wonder if it is worth the efford. Once the index diffs are supported on the normal debian server the URL-Remap code will go away again. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt with index diff support
On Mon, Sep 12, 2005 at 10:11:34PM +0200, Florian Weimer wrote: > * Michael Vogt: > > Andreas Barth implemented the server side of the index diffs > > generation and has a test-repository (with only the index-files) at > > [3]. > > By the way, the secure-testing project on alioth contains a > moderately-tested pure-Python implementation of the client side > (without ed/red depedencies). It's not a speed daemon, but it > significantly cuts down network traffic. Just to avoid confusion (and because it wasn't mentioned in the original mail), the apt implementation has it's own rred-method (in methods/rred.cc) and does not need a external ed/red. Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt with index diff support
Hi Andreas,
thanks for your feedback.
On Sat, Sep 10, 2005 at 04:46:09PM +0200, Andreas Metzler wrote:
> Michael Vogt <[EMAIL PROTECTED]> wrote:
> [...]
> > 2. merkel does not have the actual package files
[..]
> Having to specify this at the commandline is messy, is there a way to put
> this in /etc/apt.conf.d/? I've tried in vain using
>
> APT::URL-Remap::http://merkel.debian.org/~aba/debian/
> {"http://ftp.at.debian.org/debian";};
Please add (in e.g. /etc/apt/apt.conf.d/50remap):
APT::URL-Remap::"http://merkel.debian.org/~aba/debian/";
"http://ftp.de.debian.org/debian/";;
Note the quotes around the uri, if they are omitted apt will consider
the // as the start of a comment.
Cheers,
Michael
--
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
apt with index diff support
Dear Friends, the idea to have some sort of incremental update support for the archive index files (Packages,Sources) in the archive and in apt has been around for some time now [1]. Anthony Towns analysed the problem in [2] and came up with the idea to use ed-style diffs to solve the problem. Andreas Barth implemented the server side of the index diffs generation and has a test-repository (with only the index-files) at [3]. I'm happy to tell you that apt is able to use those index files now. Robert Lemmen and I implmeneted the needed support. This massively speeds up a "apt-get update". If you e.g. update daily you will have to get only ~15kb-30kb worth of update information per day (instead of 2,7mb for the complete Packages.bz2 as it is now). We believe that the code is now "good" enough for wider testing. I have setup a repository for the patched version of apt with the pdiff support. Just add this line to your sources.list file: "deb http://people.debian.org/~mvo/apt/pdiffs/ /" When fully supported by the archive, the diff support will be completely transparent, no changes on your side necessary. In the moment however, the archive does not carry the diff files, so a little hack is needed to test this. The diffs are on merkel.debian.org, so change your sources.list to point there instead of your usual mirror: "http://merkel.debian.org/~aba/debian/"; E.g. from: deb http://ftp.de.debian.org/debian sid main to deb http://merkel.debian.org/~aba/debian sid main There are two issues with using merkel: 1. There is no Release/Release.gpg file on merkel so you get "not authenticated" warnings 2. merkel does not have the actual package files To work around (2) and make it possible to still download packages (even with merkel as the only entry in sources.list) a hack was added to apt called: "APT::URL-Remap::". This allows one to remap a URI. Example: apt-get install 3dchess -o APT::URL-Remap::http://merkel.debian.org/~aba/debian/=http://ftp.de.debian.org/d +ebian/" will ensure that archives pointing to merkel are actually fetched from ftp.de.debian.org. Please note that this hack will be removed once there are servers available with both index diffs and packages (it's just to make testing easier). To work around the authentication issue you can use the "--allow-unauthenticated" switch in apt, this will suppress the authentication checking. Again once we have full support for the diffs in the archive the authentification will work (and be checked). Known issues: - the progress-bar is a bit jumpy - the total transfered data information (at the end of the update) is totally incorrect Please report success/failure/problems directly to me. There are two debug switches that should be used if you are having trouble: -o Debug::pkgAcquire::Diffs=true -o Debug::pkgAcquire::RRed=true The source code of the patch is availab in my: [EMAIL PROTECTED]/apt--pdiff--0 [4] baz repository. Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=128818 [2] http://azure.humbug.org.au/~aj/blog/2003/12/02 [3] http://merkel.debian.org/~aba/debian/ [4] at http://people.ubuntu.com/~mvo/arch/ubuntu -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#285773: ITP: smartpm -- A alternative package manager that works with dpkg/rpm
Package: wnpp Version: N/A; reported 2004-12-15 Severity: wishlist * Package name: smartpm Version : 0.28 Upstream Author : Gustavo Niemeyer <[EMAIL PROTECTED]> * URL : http://linux-br.conectiva.com.br/~niemeyer/smart/files/ * License : GPL Description : A alternative package manager that works with dpkg/rpm The Smart Package Manager project has the ambitious objective of creating smart and portable algorithms for solving adequately the problem of managing software upgrading and installation. This tool works in all major distributions, and will bring notable advantages over native tools currently in use (APT, APT-RPM, YUM, URPMI, etc). . This project is in beta testing. Please, understand that bugs are expected to be found at that stage, and there are features that still must be implemented in the forthcoming future. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux gluck 2.4.28-es #1 SMP Sun Nov 21 19:05:12 EST 2004 i686 Locale: LANG=C, LC_CTYPE=C
Re: apt-rpm article -- the features we don't have
Hi, [please CC me, I'm not on the list] > To install a package directly, with apt downloading any necessary > dependencies: > apt-get install rpmver-2.0-13498cl.i386.rpm Gustavo (maintainer of apt-rpm) has a version ready that supports http and ftp installs beside local files. This is nice and it's a feature I would love to see in debian apt (see #47379). And it's also nice for the various apt front-ends (like synaptic) to have a way to savely install local packages and get dependency resolution for that. They implement it with a special indexfile (rpmSinglePkgIndex is a subclass of the pkgIndexFile). Porting requires writing such a thing for deb packages. > There is something vague about improvements in the "upgrading > algorythm" that may or may not apply to us. I just did a (highly) unscientific test (apt-get dist-upgrade) with my (mostly) up-to-date unstable system: apt-rpm (version 0.5.15cnc3): --8<-- The following packages will be upgraded libxft2 The following packages will be REMOVED: libxft2-dev The following NEW packages will be installed: libxft-dev --8<-- debian apt (0.5.14): --8<-- The following packages will be REMOVED: gnome-core-devel libatspi-dev libbonoboui2-dev libeel2-dev libgail-dev libgal2.0-dev libglade2-dev libglademm2.0-dev libgnome-desktop-dev libgnomecanvas2-dev libgnomeprint2.2-dev libgnomeui-dev libgtk2.0-dev libgtkhtml2-dev libgtkmm2.0-dev libgtksourceview-dev libnautilus2-dev libpango1.0-dev librsvg2-dev libvdk2-dev libvdkbuilder2-dev libxft2-dev libzvt2.0-dev vdkbuilder2 The following packages will be upgraded libxft2 --8<-- So it looks like apt-rpm is doing pretty well (libxft-dev provides libxft2-dev so there is no need to remove all those pkgs) in this situation. > There is a bit about an apt shell which sounds mildly interesting. I like the apt-shell feature (IMHO it's a good mix between apt-get and higher level stuff like aptitude/synaptic) and I think we should have it as well. Porting it over to (debian) apt is easy, but it breaks the ABI as apt-shell uses new generic features from apt-rpm (I have a proof-of-concept patch ready). > At least the first three things I've mentioned above would be nice > features to have in debian. Not killer, but nice. Of course apt-rpm is > abranch/fork from out apt, so I wonder how long it will be before we > do.. There is some talk about merging between the projects (#207400). Actually is fairly easy to compile apt-rpm on a debian system (the diff is less than 500 lines). All there changes are either in the rpm/ subdir or generic and documented (and it looks like they don't break anything deb releated). bye, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Re: [bdale@gag.com: Bug#141688: FTBFS: config.sub/guess out of date]
On Sun, Apr 07, 2002 at 07:25:55PM -0500, Branden Robinson wrote: > Sending this bug report to debian-devel so that hopefully the maintainer > of this package will see it. > > Please rename your package. Yes, my fault. I renamed it to "libxbase" and just uploaded it again. Sorry for any trouble I caused you. bye, Michael > - Forwarded message from Bdale Garbee <[EMAIL PROTECTED]> - > From: [EMAIL PROTECTED] (Bdale Garbee) > To: [EMAIL PROTECTED] > Subject: Bug#141688: FTBFS: config.sub/guess out of date > Date: Sun, 7 Apr 2002 16:24:17 -0600 (MDT) > Message-Id: <[EMAIL PROTECTED]> > X-Spam-Status: No, hits=-4.5 required=4.0 tests=FORGED_RCVD_FOUND,SENT_BY_BTS > version=2.11 > > Package: xbase > Version: 2.0.0-1 > Severity: important > > This package fails to build from source on ia64 because the config.sub/guess > files are out of date. See the autotools-dev package for a good solution. > > Bdale -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 You Know You've Been Playing Too Much Nethack When... You look both ways down the corridor, start to sweat... then realise you're looking at your EMail address -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: WNPP
On Mon, Mar 27, 2000 at 11:25:46PM -0800, Joey Hess wrote: > Michael Vogt wrote: > > I packed aide for my personal needs some weeks ago. I just uploaded a > > polished > > version to http://members.xoom.com/mydebs/debian/aide. > > Cool! Do you want me to sponsor this in? If you like the package :-) Of course. The package lacks a good example /etc/aide.conf. If someone has a nice example, please send it to me. I will include it in the package. > see shy jo bye Michael -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /"\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL >> / \ o
Re: WNPP
On Mon, Mar 27, 2000 at 12:39:52PM -0800, Joey Hess wrote: > Someone should package AIDE (http://www.cs.tut.fi/~rammer/aide.html). It's > a free tripwire replacement. I packed aide for my personal needs some weeks ago. I just uploaded a polished version to http://members.xoom.com/mydebs/debian/aide. > see shy jo bye Michael -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /"\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL >> / \ o
Re: Debconf question
On Mon, Mar 27, 2000 at 03:00:43PM -0800, Joey Hess wrote: > Michael Vogt wrote: > > Ok, stupid me. I had a line likes this in my debian/config: > > "db_input medium shared/ldapns/ldap-server || true" > > So, the question is allways asked. > > I don't see why the question would always be asked. Debconf defaults to > only asking questions if the user has not seen them before. I think the > above should work just fine. Human error (strikes again). You are right, of course. I set my debconf to "Show all old questions again and again" :-) (stupid me). > > This works, debconf asks for the ldap-server, if libpam-ldap is the first > > package that sets this value and if shared/ldapns/ldap-server is allready > > owned by another package, debconf is quiet. > > That's incorrect, multiple packages can own a value, and multiple owners > may be set by debconf before *any* of the packages is configured. Yup. Very incorrect and very complicated. I removed this crap and it works like a charm. Debconf is realy nice :) > see shy jo bye Michael -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /"\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL >> / \ o
Re: Debconf question
> > I tryed adding this to the template and config file of both packages and > > hoped that after installing one lib, "db_get shared/ldapns/ldap-server" > > for the other lib would return the value entered in the first lib. > > But it didn't work. Any help would appreciated :) > > Hm. That should work. Any package can access the values of any question in > the debconf database. Ok, stupid me. I had a line likes this in my debian/config: "db_input medium shared/ldapns/ldap-server || true" So, the question is allways asked. Currently I do something like this: ---8<-- db_metaget shared/ldapns/ldap-server owners if [ "libpam-ldap" = $RET ] || [ "$1" = "reconfigure" ]; then db_input medium shared/ldapns/ldap-server || true if db_go ---8<-- This works, debconf asks for the ldap-server, if libpam-ldap is the first package that sets this value and if shared/ldapns/ldap-server is allready owned by another package, debconf is quiet. Do you think this is ok? Or is there a better way to handle this? > see shy jo bye Michael P.S. debconf for libpam-ldap and libnss-ldap is almost complete. I am looking for an expert for PAM. I made a set of ldap enabled pam files for libpam-ldap (i used the pam.d/* in base-files as template) and I would be very happy if someone could have a look at them. -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /"\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL >> / \ o
Debconf question
Dear Friends I am working on debconf support for libnss-ldap and libpam-ldap. Since both share some common information (ldap-server and ldap-base-dn) I want to have a shared debconf entry (say shared/ldapns/ldap-server,base-dn). I tryed adding this to the template and config file of both packages and hoped that after installing one lib, "db_get shared/ldapns/ldap-server" for the other lib would return the value entered in the first lib. But it didn't work. Any help would appreciated :) bye Michael -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /"\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL >> / \ o
alternatives
Dear Friends We have a "/etc/alternative/editor", but not a "x-editor". Wouldn't this a usefull addition for the alternative-system? best regards Michael -- GPG Fingerprint = EA71 B296 4597 4D8B 343E 821E 9624 83E1 5662 C734 /"\ o \ / ASCII RIBBON CAMPAIGN /|\ XAGAINST HTML MAIL >> / \ o
