We need more testers to the new incoming repo (how-to)

gotjazz · Post by **gotjazz** » Sun Jul 31, 2011 11:05 am

hrm I've played around with apt-pinning quite a bit in the past and I think that might somewhat mess up my transition to this new repo here. could someone with an unchanged /etc/apt/preferences file please post the content of said file?

thanks a lot

GeneC · Post by **GeneC** » Sun Jul 31, 2011 11:08 am

Here ya go~!

Code: Select all

Package: *
Pin: release o=linuxmint
Pin-Priority: 700

Package: *
Pin: origin packages.linuxmint.com
Pin-Priority: 700

Package: *
Pin: release o=Debian
Pin-Priority: 500

gotjazz · Post by **gotjazz** » Sun Jul 31, 2011 7:57 pm

cheers mate - should be alright the way I have it then. just to be sure i commented out most of my own additions plus the corresponding repos. seems i was a bit ahead of the current incoming status on debian testing and that's why nothing happened (although i haven't updated recently)

ginjabunny · Post by **ginjabunny** » Sat Aug 06, 2011 12:34 pm

I have just switched to mintupdate-debian on my LMDE and had a thought, this may have been already suggested.

I'm not sure if this doable (or it may already do this), but rather than have just one repo as "debian.linuxmint.com" why not make mintupdate-debian so it just holds the Update Pack list of packages to be installed but still get them from the local/country specific debian.org repo if they are still on there, is this a possible way of doing update packs? I don't know if the debian.org repos only hold the latest versions but if this was the case then that is where my idea falls down as the update pack list would soon be out of step with the debian.org repo but maybe this could be taken into account.

One of the downsides I can see of just using debian.linuxmint.com is that it would get hammered ever time you release an Update Pack, but if you could spread it out across the debian.org repos to get packages with versions listed in the Update Pack it would lighten the load.

Just a thought.

GB

AlbertP · Post by **AlbertP** » Sat Aug 06, 2011 2:50 pm

Debian does not keep superseded versions online in the testing repo, so people installing something from the repository may install something that belongs to a next update pack. Or people use terminal (apt upgrade/dist-upgrade) instead of mintupdate and they get a mix of the update pack and regular Debian.

ginjabunny · Post by **ginjabunny** » Sat Aug 06, 2011 3:31 pm

I realise that the debian.org repository will get updated between releases of the update packs but if the mintupdate-debian program tested the required file names in the local debian.org repo it could use that instead of the linuxmint.com one which should hopefully speed it up and take the load off linuxmint.com.

Just an idea which would make it faster for people who have said that they had to revert back to local debian.org repos because the linuxmint.com one is very slow from their location.

Obviously what I suggest would need mintupdate-debian to check different repositories for each package it wants to fetch, not sure if apt could handle what I am suggesting but if mintupdate-debian downloaded what it needed from the nearest repo to a local folder then it could get apt to install then all from a local folder.
Also when the update pack is first released most of the packages needed would be in the local debian.org repo but over time probably wouldn't be so would have to go to linuxmint.com to get them.

GB

kmb42vt · Post by **kmb42vt** » Sat Aug 06, 2011 4:26 pm

ginjabunny wrote:I have just switched to mintupdate-debian on my LMDE and had a thought, this may have been already suggested.

I'm not sure if this doable (or it may already do this), but rather than have just one repo as "debian.linuxmint.com" why not make mintupdate-debian so it just holds the Update Pack list of packages to be installed but still get them from the local/country specific debian.org repo if they are still on there, is this a possible way of doing update packs? I don't know if the debian.org repos only hold the latest versions but if this was the case then that is where my idea falls down as the update pack list would soon be out of step with the debian.org repo but maybe this could be taken into account.

One of the downsides I can see of just using debian.linuxmint.com is that it would get hammered ever time you release an Update Pack, but if you could spread it out across the debian.org repos to get packages with versions listed in the Update Pack it would lighten the load.

Just a thought.

GB

Actually, Clem and Co have signed an partnetship with AYKsolutions that provides two new servers, one of which "to host the new “Incoming” and “Latest” Debian Testing repositories used by LMDE, and it features 1Gbps unmetered bandwidth", so it should probably stand up to the monthly update pack downloads okay. Here's the actual blog post: http://blog.linuxmint.com/?p=1787

ginjabunny · Post by **ginjabunny** » Sat Aug 06, 2011 5:08 pm

but is this 1Gbps service fast from all over the world? Maybe in some countries a local repository would still be preferable.

kmb42vt · Post by **kmb42vt** » Sat Aug 06, 2011 5:26 pm

ginjabunny wrote:but is this 1Gbps service fast from all over the world? Maybe in some countries a local repository would still be preferable.

Probably very doable and I would guess that that could begin happening sometime after the respin has been released and a bit of update pack feedback comes in. But that's just a guess. As far as I'm concerned, your question should be among the top 5 items of the "list of things to check after the respin is released" (if there is such a thing).

zerozero · Post by **zerozero** » Sat Aug 06, 2011 7:03 pm

Ginjabunny, if i understand correctly, what you are proposing is this

The next step is already in progress and it consists in developing a network of mirrors for the new Debian repositories.

http://blog.linuxmint.com/?p=1799

ginjabunny · Post by **ginjabunny** » Sun Aug 07, 2011 3:45 am

No, what I was proposing was to use the existing local debian.org mirrors if they contain the packages listed in the update pack, but if not there then go to linuxmint.com, Again this is just an idea, not sure if it is doable.

For example, the update pack contains a list of 5 packages, for this example I'll call then A to E, so mintupdate-debian would get a list of what is on the local debian.org server (in my case UK) and merge that with a list of what is on linuxmint.com, so mintupdate-debian would do something like

- needs package Av1.0 - uk.debian.org has Av1.0 - linuxmint.com has Av1.0 - get from uk.debian.org
- needs package Bv5.6 - uk.debian.org has Bv5.7 - linuxmint.com has Av5.6 - get from linuxmint.com
- needs package Cv2.2 - uk.debian.org has Cv2.2 - linuxmint.com has Av2.2 - get from uk.debian.org
- needs package Dv1.0 - uk.debian.org has Dv1.0 - linuxmint.com has Dv1.0 - get from uk.debian.org - get failed use linuxmint.com
- needs package Ev1.1 - uk.debian.org has Ev1.2 - linuxmint.com has Ev1.1 - get from linuxmint.com

It downloads them into a directory on your PC and installs them from there.

When the update pack is released then most of the packages would probably be on the debian.org mirrors but over time as they get updated with new versions of packages then it would more likely tend toward linuxmint.com.

Alternatively at great expense setup lots of linuxmint mirrors.

AlbertP · Post by **AlbertP** » Sun Aug 07, 2011 5:54 am

Packages are already downloaded to a directory on your PC before they get installed, when you use apt. By the way, to install a package from your PC dpkg is used instead of apt.

ginjabunny · Post by **ginjabunny** » Sun Aug 07, 2011 6:13 am

I know that, it is how they get there that I am saying could be done differently, reread what I wrote.

gat · Post by **gat** » Wed Aug 10, 2011 11:02 pm

Is there any collaboration between debian (proper) and L.M.D.E. with this new pack-update-rolling idea?

ginjabunny · Post by **ginjabunny** » Sat Aug 13, 2011 10:13 am

@gat - I don't know but I doubt it some how, they're probably too busy working on Debian.

(my suggestion was based on the fact that LMDE currently uses debian testing repositories, so why not use them in the mint update-pack set up if the package are still available)

rhodry · Post by **rhodry** » Sat Aug 13, 2011 9:39 pm

I think this is the correct subject to post this under as it concerns mirrors of "latest" & "incoming"?

I had recently moved my main LMDE-Xfce install to track "Sid" because of some issues with my local ISP Linux mirror not carrying the Linuxmint repos but carrying a full Debian mirror.

Anyway, that situation changed and they finally agreed to carry a full Linuxmint mirror, including "latest" & "incoming" repos!!

So, I decided to do a fresh install on my test machine of the April LMDE-Xfce iso and track 'latest" and test mintupdate-debian with the BIG (near 600Mb) update. It all updated beautifully and heaps of kudos to all concerned. All I had to do was remove kexec-tools and add the linux-headers app for the new kernel (both issues well documented on these forums elsewhere) before re-booting.

There was, however, one error that occurred that I really would like the developers to have a look at before the new re-mix if possible. When running mintUpdate, the message given was that I was (paraphrasing) 'not running an appropriate debian mirror' and so I got NO information about the Update Packs. I had my sources.list pointed to (in part):

deb http://mirror.internode.on.net/pub/linu ... an/latest/ testing main contrib non-free

I investigated this because I was sure mintupdate-debian (like all mint tools) would be a python script. Sure enough, when looking at "/usr/lib/linuxmint/mintUpdate.py" there is a section headed

# Try to update the local update pack level

and the code in that section is hard-coded to look for the url at debian.linuxmint.com!

This is the problem! Whilst the code looks for only for the primary server, no-one running a mirror of "latest" or "incoming" will receive any information about the Update Pack status. The upgrade itself goes on to work ok because, in the end, it is just doing a dist-upgrade against the repos specified in sources.list.

Now I know next to nothing about python scripting but surely it would be a fairly trivial change to have the code do a text search on the repo names for the latter part of the url only; so,
this bit "/latest/ testing main contrib non-free"
rather than the full url address? Only the server address should be different; the file structure is what is important.

If this is not possible, why would anyone using a mirror bother using mintUpdate. You may as well just do dist-upgrade straight against the repo. Given how well the update itself worked on such a large update, I would be quite happy to put this 'latest' version on every one of my supported users machines, PROVIDED they get all the relevant information when using a mirror.

Well done again folks, LMDE truly is looking like becoming THE solution for literally hundreds of users in my realm of influence.

rhodry.

ps: Just a piece of advice to anyone still contemplating "the BIG update" before the re-mix arrives. If you are happy using Abiword/Gnumeric combination rather than Libreoffice, do:

$ sudo apt remove --purge libreoff*

before you do the update. Saves you hundreds of Mb of download!

zerozero · Post by **zerozero** » Sat Aug 13, 2011 10:15 pm

rhodry, i would suggest contact Clem directly (email or pm) regarding this subject.

Post by **clem** » Sun Aug 14, 2011 10:15 am

It only does that to get the update pack info and number... so it's not a critical issue, since for most people the mirrors are used to spread the load and to gain performance. It's a good point however, and I'm adding it to my todo list

rhodry · Post by **rhodry** » Sun Aug 14, 2011 8:28 pm

clem wrote:It only does that to get the update pack info and number... so it's not a critical issue, since for most people the mirrors are used to spread the load and to gain performance. It's a good point however, and I'm adding it to my todo list

Can't ask for any more than that. Thanks Clem.

I did not "study" the code too closely because Python is not my forte.

You're right though , it did not affect the update per se. My only concern was really about user support; if I have two people using the same system, one aimed at original server & one at a mirror, they will see different process (not outcome though!). I will document something temporary to remind me to tell people.

You must be proud of how well LMDE is coming along? You should be anyway!

Between your expertise & our ISP's continued support of its Linux mirror (and Boo's upcoming KDE) you have hundreds of "happy campers" in this neck of the woods.

cheers,
rhodry.

whirly · Post by **whirly** » Mon Aug 15, 2011 4:08 pm

i've been getting a 'failed to fetch' message for a week or two now. I thought it might sort itself out but now i see everyone's getting a 3.xx kernel and i don't get the option to bork. Is it still the list on page one? i've got those. i added a few ppas for a GNOME experiment, but i was quite sure i purged everything.
Failed to fetch http://packages.linuxmint.com/dists/debian/Release Unable to find expected entry 'main'./binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)

I'm impressed with the overall performance, and as i'm just a user, and a light one at that, i know i could leave it as is. it just seems like more fun to be on top of it all. my update shield alternates between green check, and red x which is why i thought it would sort itself out
I like all the gui functionality and that may be where my problems started.
i still get some updates out of mu de and successsfully got update packs 1 and 2 from it.
any advice would be appreciated.
i'm d/l ing the new rc one right now too
deb http://packages.linuxmint.com/ debian main upstream import backport romeo
deb http://security.debian.org/ testing/updates main contrib non-free
deb http://www.debian-multimedia.org testing main non-free
deb http://debian.linuxmint.com/incoming testing main contrib non-free

Linux Mint Forums

We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

new incoming repo

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)

Re: We need more testers to the new incoming repo (how-to)